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Abstract 


This is the final report for the Montana Advanced Automatic Crash Notification (AACN) 
Project. The long-term goals of this research were to reduce the time to deliver emergency care 
to motor vehicle crash victims; to make improved (better informed) triage, transport and 
treatment decisions where choices exist; and to improve long-term rehabilitation outcomes for 
motor vehicle crash survivors. The specific objectives of this project involved characterizing 
Montana’s current data infrastructure and developing recommendations for incorporating new 
information technologies to enhance the trauma response system, expanding community 
rehabilitation services to crash victims, and exploring ways to integrate disability and 
rehabilitation providers’ more fully into the Montana Trauma Care System. 


In the first task, researchers reviewed documentation of data system and interviewed data 
managers to assess the status and processes of Montana’s crash data infrastructure. They created 
a matrix of data elements of each independent system with recommendations for increasing the 
consistency across systems. They also produced a series of flow diagrams that characterized the 
system. These were used to design the introduction of AACN data. 


In another task, the researchers demonstrated the introduction and use of AACN data. 
Researchers conducted extensive planning sessions with representatives from organizations that 
represented the emergency response system to construct the procedures for introducing AACN 
data. Next, they conducted a simulated live demonstration of the procedures. The results showed 
only small changes to existing protocols are necessary to ensure the OnStar data is captured and 
made available for use in field triage and transport decision-making and post event research. 
After the demonstration, the system was implemented for nine months in Missoula, Montana to 
test its functionality. While four SOS and four “Good Samaritan” calls were received, no crash 
events involving AACN were recorded during this period. Nonetheless, given that the approach 
for getting AACN information to emergency medical providers is both simple and inexpensive, 
operation of the system in Missoula should be continued. 


Researchers also conducted three investigations designed to develop and expand models for 
providing community supports to individuals injured in car crashes. First, the researchers worked 
with staff of the Brain Injury Association of Montana (BIAMT) to conduct a survey of 
participation in the Brain Injury Help Line by Emergency Departments of hospitals across the 
State. This showed the majority of referrals came from four hospitals. BIAMT developed a 
campaign to expand participation in the Brain Injury Help Line. Overall referrals to the Help 
Line increased from 148 to 222 annually. In the final study, the researchers used these data to 
estimate the budget needed to expand the service to meet the potential need. That analysis 
suggests if the service was expanded to include individuals with serious injuries from car 
crashes, it could be operated for $150,000 to $160,000 annually. 


In summary, researchers concluded the simple and inexpensive approach described here enables 
AACN data to be captured and archived as well as shared in real time with emergency medical 
providers responding to motor vehicle crash scenes. Although the number of active AACN 
vehicles is apparently low in Missoula, efforts to further integrate AACN data into emergency 
medical response procedures might be pursued in other areas of Montana using the same 
approach to evaluate the systems actual performance. Finally, the Brain Injury Help Line should 
be funded at $160,000 annually. 
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1 Introduction 


1.1 Background 


Highway crashes exact an enormous human and financial cost. In 2009, the most recent year for 
which national data is available, 2.2 million Americans were injured in 10.8 million crashes. 
These crashes resulted in 250,000 Americans suffering life-threatening injuries and 35,900 
deaths (National Highway Traffic Safety Administration, 2012). In addition to the tragedy 
associated with the crash deaths, many of those injured in crashes survive with long-term 
disabilities. These injuries have long-term impact on the quality of life for both the injured 
individuals and their families. For example, many are unable to return to work or are limited in 
the type of work they are able to do. The economic costs associated with serious crash injuries 
(excluding value for pain and suffering) amount to about $100 billion each year (Blincoe et al., 
2002). 


The problem is proportionately more acute in rural states. In particular, Montana, Louisiana, 
Arkansas, South Carolina, and West Virginia are among the states with the highest motor vehicle 
crash fatality rates in the nation. Figure 1 shows how these rural states rank relative to other 
states using the measure of fatality rate per 100 million vehicle miles traveled. 


MT = 2.01 (highest in the US) 


Fatality Rate per 
100 Million VMT 


< 0.89 


0.90 to 1.17 


1.18 to 1.45 
1.46 to 1.73 


> 1.74 


Figure 1. Motor Vehicle Fatality Rates per 100 Million Vehicle Miles Driven (NHSTA, 2009) 


In Montana in 2010, there were 189 people killed and more than 7000 people injured in motor 
vehicle crashes (MDT, 2012). Similar numbers of fatalities and injuries occur in Montana every 
year. 


Research indicates that key factors in reducing motor vehicle related deaths, injuries, and 
resulting disability include but are not limited to improved highway design and maintenance; 
improved crash detection; reduced time to deliver emergency care to crash victims; improved 
(better informed) triage, transport and treatment decisions; and expanded availability of and 


access to appropriate emergency medical and effective rehabilitation services (Blow et al., 1999; 
Davis et al., 2005; Evanco, 1996). 


While each of these factors may be treated separately, maximizing emergency response 
performance may best be facilitated through the development of a comprehensive and inclusive 
trauma care system. New information technologies are emerging that offer opportunities to 
reduce crash deaths and disabilities. To take advantage of these new technologies, however, they 
must be integrated into the overall emergency response system. Moreover, the effort to take 
advantage of these new technologies may facilitate progress toward developing a comprehensive 
trauma care system. This calls for an examination of the data infrastructure and an exploration of 
methods to fit the new technology into that infrastructure, as well as an examination of the 
trauma system and how disability and rehabilitation providers might fit into it. 


1.2 Emerging Technologies, Systems, and Tools 


Many new information processing technologies are emerging that offer potential improvements 
to motor vehicle-crash and trauma response systems, including hand-held data collection and 
transmission devices, geographic information systems (utilizing real-time data from satellite- 
based global positioning systems), and more. One such system is Automatic Crash Notification 
and Advanced Automatic Crash Notification (ACN/AACN) systems. 


Automatic Crash Notification (ACN) systems, with in-vehicle crash detection sensors, Global 
Positioning Satellite (GPS) receivers, and wireless telematics are an example of a new 
information technology that can facilitate emergency response and subsequent treatment. These 
systems automatically sense crashes in which air bags are deployed (or other pre-determined 
crash thresholds are exceeded), and immediately report the occurrence and location of the crash. 
Additionally, in a growing number of vehicles with AACN, detailed crash information such as 
crash severity (crash delta velocity), principal direction of force (frontal, side, rear impact), 
whether the vehicle rolled, whether multiple impacts occurred, etc., is also sent wirelessly with 
the automatic crash notification alert. This information is transmitted via an automatic cellular 
phone call from the crashed car to a Telematics Service Provider (TSP) such as OnStar or Cross 
Country Group. 


As of October 2011, OnStar reported there were about 6 million AACN equipped vehicles on the 
road (Sustainable Brands, 2011). Recently they introduced an aftermarket product called ‘For 
My Vehicle’ (FMV) that could enable more than 100 million vehicles on the road to replace their 
rear view mirror with a new device that would provide the vehicle with ACN capabilities. 


In addition to providing immediate notification and crash location information, ACN/AACN 
technology has the potential to improve emergency message routing and response after a serious 
car crash. Currently, as demonstrated in this project, AACN systems provide data that can be 
used together with new ‘tools’ to support the triage, transport, and treatment decisions of pre- 
hospital care providers and public safety personnel. These tools consist of computerized 
algorithms that take advantage of the information provided by AACN systems (in the crashed 
vehicle), as well as first responder observations at the scene, and couple these crash specific data 
with geo-coded databases of local Emergency Medical Services (EMS) and hospital resources 
(e.g., air medical services and trauma centers). Crucial to this capability is the development 
occupant injury severity predictors that are able to operate in near real time (Kononen et al., 
2011; Augenstein et al., 2001). The development of these algorithms has prompted the American 


2 


College of Surgeons Committee on Trauma and the Centers for Disease Control and Prevention 
to issue new guidelines for Field Trauma Triage. These guidelines specifically acknowledge the 
utility of the crash telemetry data for improving trauma triage decisions (CDC, 2009; CDC, 
2008). 


1.3 Expanded Perspective to Support Follow-up for Crash Victims 


The emphasis on response to injuries from motor vehicle crashes typically focuses on immediate 
care from the point of the event through medical treatment at a clinic or hospital. A public health 
model takes a broader view, a view that spans the time from crash events through rehabilitation 
and community reintegration. Public health defines prevention to include primary, secondary, 
and tertiary prevention. The goal of primary prevention is to prevent specific events (e.g., motor 
vehicle crashes) or conditions (e.g., injuries) from occurring. The goal of secondary prevention is 
to intervene as quickly as possible to limit the consequences of an adverse event. The goal of 
tertiary prevention is to provide services and support to reduce the negative consequences of the 
event or conditions, and to maximize the outcome of the response or treatment. 


Consistent with secondary and tertiary prevention goals, it is expected that disabilities associated 
with motor vehicle crash injuries can be reduced by: 1) early detection of those crash-related 
injuries that might lead to disabilities and 2) making improvements in the coordination, tracking, 
and delivery of community rehabilitation, and integration services for crash victims. To 
accomplish this, researchers must first develop an understanding of the possible short and long- 
term disability consequences of specific motor vehicle crash injuries. In addition, a mechanism 
to identify and track motor vehicle crash victims with the potential for disability must be 
implemented across the state so survivors can be effectively matched with rehabilitation 
providers in their area and follow up support provided on a continuing basis. 


1.4 Existing Montana Crash Infrastructure 


A critical aspect of the Montana AACN project has been the recognition that all work performed 
on the project had to consider the existing Montana crash infrastructure as well as the plans for 
its evolution and improvement. With that in mind, the following discussion summarizes some of 
the key considerations of the infrastructure as they relate to the project. 


The motor vehicle crash-related data infrastructure (as used here) consists of data derived from 
police accident reports, pre-hospital care reports, public safety 9-1-1 records, trauma registry 
information, hospital treatment and referral packages, rehabilitation records, and community 
disability support records. It also includes the tools, procedures, and protocols to collect, 
distribute, organize, utilize, and archive the information. As in most sectors of society, new 
information technologies are improving the performance of systems of all types. This is true for 
emergency response to motor vehicle crashes where new information technologies offer 
opportunities to reduce crash-related deaths and disabilities. As noted earlier, one such 
technology is Advanced Automatic Crash Notification. 


To achieve the promise of AACN and other new technologies, however, the data that they 
provide and the procedures and protocols for their use must be integrated into a comprehensive 
and coherent emergency response system that spans the time from the crash event through 
rehabilitation and community reintegration. It is particularly important that the information 
generated through new technologies be compatible with existing emergency response and trauma 
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care data systems. As such, the effort to take advantage of these new technologies may facilitate 
progress toward the development of such a comprehensive trauma care system. 


1.5 Emergency Response, Trauma, and Rehabilitation Care in Montana 


Serious motor vehicle crashes (MVC) begin a series of events that usually engages emergency 
response, trauma, and rehabilitative care systems. Figure 2 presents a rudimentary outline of 
expected pathways from crash injury and emergency response through community rehabilitation 
and integration. As the severity of injury resulting from a crash increases, survivors pass through 
increasingly more stages of the continuum. 
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Figure 2. Expected pathway from crash injury through rehabilitaiton 


To optimize the care and provide the best outcome for injured crash victims, a comprehensive 
trauma system is required. Ideally, such a system would provide a continuum of care from the 
initial emergency notification to pre-hospital care (at the scene and during transport), through 
emergency department treatment and definitive surgical care at an appropriate medical facility, 
and finally to rehabilitation and integration back into the community. Montana has begun 
developing such a comprehensive trauma care system (TCS). 


1.5.1 The Montana Trauma System 


While responding to a traumatic injury in a rural state such as Montana poses many challenges, 
the basic elements of a comprehensive care system are similar to those required in other states. 
These include detecting emergencies (sometimes in isolated areas where the event may not be 
observed), determining its location accurately, responding quickly with appropriate emergency 
care at the scene, and transporting the injured to medical treatment facilities where appropriate 
emergency trauma care and follow-up medical and rehabilitative care can be provided. The 
seamless transition between each phase of care, while making efficient use of health care 
resources, is one of the hallmarks of a modern trauma system. 


The first comprehensive plan for a Montana statewide trauma care system was developed in 
1994. This plan was addressed in comprehensive trauma system legislation in 1995. The plan 
encompassed trauma from all causes, including motor vehicle crashes. Unfortunately, the plan 
was not immediately funded. In 1999, the State legislature did authorize funding for developing 
and operating a trauma system, and the program has steadily grown through various funding 
mechanisms and a strong, statewide commitment by many volunteers. 


Montana Codes Annotated (MCA) 50-6-401 established the Montana Trauma Care System that 
requires the Montana Department of Public Health and Human Services to plan, coordinate, 
implement, and administer a statewide trauma care system that involves all health care facilities 
and emergency medical services within the State. It also calls on the Department to develop a 
state trauma registry. Moreover, it articulates extended roles and responsibilities of the State 
Trauma Care Committee, calls for regional committees, and describes linkages with the 
emergency medical services advisory council. 


Figure 3 shows the State’s three trauma regions (Western, Central & Eastern), each of which is 
guided by a Regional Trauma Advisory Committee (RTAC). Montana’s State Trauma Care 
Committee (STCC) oversees these committees, and provides advice and direction to the 
Montana trauma care and Emergency Medical Services (EMS) systems. | 


Figure 3. Trauma Regions in Montana (adopted from Montana DPHHS website)’. 
1.5.2 Rehabilitation and Disability Services in Montana 


While not specifically mentioned in legislation, the trauma care system has consistently included 
rehabilitation. In practice, this has emphasized medical rehabilitation providers. Yet, for many, 
rehabilitation does not end with medical discharge. Rather, it often extends into the programs of 
many community-based rehabilitation providers, including such programs as the State vocational 
rehabilitation system and the Brain Injury Association of Montana (BIAMT). In fact, as Figure 2 
suggests, entry into the Montana rehabilitation system often occurs first through one of these 
programs when unanticipated disabilities emerge because of injuries. 


1.5.3 Data Systems in Montana 


While there has been significant progress in developing an integrated trauma care system and 
parallel progress in creating an integrated data system that allows for monitoring and quality 
improvement, there remains room for improvement. In particular, advanced sensor and 
information technologies, which are coming of age, are expected to introduce new types of data 
that should be integrated into existing data systems in Montana. One such information 


' http://www.dphhs.mt.gov/ems/emstrauma/traumaover.htm 
* http://www.dphhs.mt.gov/ems/emstrauma/rtacmap.html 
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technology is referred to as Automatic Crash Notification and Advanced Automatic Crash 
Notification systems (ACN/AACN). Integrating data from these new technologies provides the 
opportunity to further upgrade the existing data infrastructure. 


Various emergency responders and treatment facilities currently document both the crash event 
and resulting crash injuries (including patient follow-up). For the most part, these are separate 
and independent data records. Figure 4 shows the post-crash sequence of events from Figure 2, 
but with some additions. The events in the rounded rectangles (shaded pink) represent a key step 
in the chain of care that will ultimately provide input into the full crash-injury-rehab data record. 
Various data sources, which currently document each stage of the response, are indicated above 
each event. 
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Figure 4. Key Steps that Provide Input to the Crash Injury-Rehab 


As is typical in most states, these data sources are usually separate (some still on paper) and not 
well integrated or electronically linked. For example, the Emergency Medical Services and 
Trauma System Section of the Montana Department of Public Health and Human Services 
maintain a Statewide Trauma Registry. However, this registry is not currently linked with other 
data records that describe the crash event and follow-up treatment. One of the goals of this 
project was to explore opportunities for a comprehensive integrated MVC response data system 
that will provide this linkage and incorporate new data provided by emerging technologies such 
as ACN/AACN. 


1.6 Goals of This Project 


It is important to note the project team has worked closely with the research technical panel 
established by Montana Department of Transportation (MDT) to oversee the direction and 
progress of the project. With inputs provided by the technical panel, a team of engineers from 
CUBRC® in Buffalo, NY and public health researchers from the University of Montana in 
Missoula identified four major goals for the project. The goals included: 1) Characterize 
Montana’s current motor vehicle crash-related data infrastructure, including procedures and 
protocols, and develop a framework for creating a comprehensive integrated motor vehicle 


crash-related response data system — including ACN/AACN - and submit it to stakeholders for 
review; 2) Provide selected demonstrations of the comprehensive integrated crash response data 
system (including disability measures) and illustrate its use for crash response, research, and 
analysis of system performance; 3) Expand the Montana Traumatic Brain Injury Registry and 
Resource Facilitation Program and assess the potential for integrating it into the Montana 
Trauma System; and 4) Investigate approaches for increasing participation of disability and 
medical rehabilitation providers in the trauma systems. 


1.6.1 Overall Research Plan 


Consistent with the four goals of the project a research plan was constructed. During the conduct 
of the project, it was necessary to modify the research plan to address suggestions provided by 
the Research technical panel. As noted in Figure 5, the research plan consisted of two phases, the 
first of which was addressed in this project. The Phase | activities consisted of four inter-related 
tasks. Each task addressed one project goal. Figure 5 illustrates the relationship between the four 
tasks and their primary products/outputs. Each task is identified by a circle and its primary 
products and outputs are shown in the rectangles. It should be noted that based on the Research 
Panel recommendations, Task 2 was revised and focused to provide and demonstrate the ability 
to receive OnStar crash data at PSAPs and distribute the data to prehospital and hospital-based 
stakeholders. 


The following report sections present a justification for each task, statement of the objectives and 
activities designed to accomplish the task, detailed description of the methods used to achieve 
the stated objectives, and a description of expect findings and products. 
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Figure 5. Overview of revised tasks in the research plan 
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2 Montana’s Motor Vehicle Crash-Related Data 


2.1 Infrastructure 


One premise of this research is that new technologies (e.g., ACN/AACN) have emerged that 
have the potential to improve the efficiency and effectiveness of emergency response, treatment, 
and rehabilitation of people injured in motor vehicle crashes. These technologies will both 
change the information collected and change the way that information is managed. In the 
process, they have the potential to transform the systems of response and rehabilitation to 
increase their integration and effectiveness. In order to take the next step, however researchers 
must understand the existing trauma response data architecture. 


Motor vehicle crash (MVC) data describe road vehicle collision events. MVC data are gathered 
and used throughout emergency response processes. They are derived from public safety 911 
records, law enforcement motor vehicle crash reports, pre-hospital care reports, hospital records, 
and trauma registry information. The complete MVC data infrastructure also includes the tools, 
procedures, and protocols to collect, distribute, organize, utilize, and archive the information. 


New information technologies are improving the potential and performance of emergency 
response to motor vehicle crashes. The new information technologies offer opportunities to 
reduce crash-related injury, disability, and death. Two such technologies are Automatic Crash 
Notification (ACN), and Advanced Automatic Crash Notification (AACN). ACN and AACN 
take advantage of emerging in-vehicle crash detection systems that automatically transmit data 
from motor vehicles involved in crashes. These technologies have the potential to provide actual 
crash data in near-real time to support the dispatch of emergency responder services and assist in 
triage, transport, and treatment decisions via earlier and more accurate data about MVC. Further, 
employing these data can potentially increase the integration and effectiveness of the response 
and rehabilitation systems. This has been shown in some communities in the United States, and 
is potentially true for Montana. Optimal utilization of these technologies requires a framework 
and a plan to create a comprehensive integrated MVC data infrastructure, whereby data from 
ACN/AACN, 911 call centers, emergency responders, and hospitals can be integrated. 


The objective of Task 1 of the Montana Crash Notification Project was to characterize 
Montana’s current MVC data infrastructure, procedures, and protocols in order to develop a 
framework (i.e., requirements) for creating a comprehensive integrated motor vehicle-crash 
response data system that includes ACN and AACN data. This document reports on these 
objectives. 


2.2 Methods 


Research methodology was descriptive and qualitative, focusing on experts and key informant 
interviews. 


2.2.1. Technical Panel 


First, researchers convened with the Research project Technical Panel to guide the direction and 
decisions that were pertinent to Task 1. Members of the Technical Panel are listed in Appendix 
A. 


2.2.2 Key Informant Interviews 


To characterize Montana’s MVC data infrastructure, researchers gathered information from key 
informants about activities and tools associated with the collection and compilation of MVC 
data. The initial group of key respondents was selected in consultation with the research project 
technical panel. Key informants in this project were administrative leaders and key technical 
staff of agencies, programs, and organizations involved in collecting, analyzing, and using data 
concerning motor vehicle crashes in Montana. The data were gathered from key informants via 
face-to-face or telephone interviews. 


Next, a snowball sampling technique was used to identify additional key informants to represent 
the known universe of Montana’s MVC data infrastructure. From the initial interviews, it was 
discovered that significant variability exists across local direct service agencies, such as 911 call 
centers, fire, emergency medical services, and law enforcement. The research decision was made 
to include one or two representative agencies per provider type (e.g., 911 center, police, EMS, 
etc.) with the most consistent, standardized, and state of the art procedures and technology. As a 
result, when local direct service response systems are described, it should be understood to be a 
nearly best case scenario within Montana, and a scenario towards which other agencies of the 
same provider type are likely to be headed. A complete listing of key informants is found in 
Appendix A. 


The interviews followed a protocol developed to permit the characterization of current activities 
and tools associated with the collection, compilation, and use of the Montana agency’s MVC 
data. The interview focused on: 

Which MVC data are collected 

When MVC data are collected in relation to the actual MVC 

How MVC data are gathered, sent, and archived 

How MVC data are utilized 

Challenges or limitations with their MVC data 

What authority influences data collection, transmittal, use, and storage 

Affiliate agencies 

Future directions and expectations of the agency’s MVC data 

Agency challenges to integrating ACN/AACN data. 


Data dictionaries were requested and obtained from each represented agency. 
2.2.3 Analysis 


After interviews were conducted and supporting documents obtained, a system-oriented 
approach was employed to analyze the data and to describe Montana’s MVC data infrastructure. 
The notes from the interviews were reviewed, analyzed, checked for accuracy with the key 
informant when necessary, and summarized into a written report. That report and summary, 
which describes the data infrastructure and data-related events and activities for each of the 
participating agencies, follow herein. It should be noted local Public Service Answering Points 
(PSAPs), or 9-1-1 centers, are the keystone of the emergency response system. Dispatchers link 
the individuals involved in motor vehicle collision events to emergency medical services and law 
enforcement. Therefore, the description of Montana’s Crash Related Data Infrastructure is 
broken-down into time increments in relation to the 9-1-1 call. 
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Next, a Montana MVC Data Book was developed. The Data Book is a compilation of the data 
dictionaries provided by agencies that collect MVC data in Montana.* 


The data dictionaries were cross-referenced with the Vehicular Emergency Data Set (VEDS) 
recommendations. VEDS is a national data standard that identifies useful and critical crash and 
medical elements needed to provide an effective emergency response to vehicular emergency 
incidents (ComCARE, 2004). Several key informants identified VEDS as a good guideline for 
incorporating ACN data across all Montana MVC agencies. VEDS was used in the proof of 
concept for the national Next Generation 911 Initiative, with the goal of enabling the 
transmission of voice, data, or video from different types of communication devices to PSAPs 
and onto emergency responders (9-1-1 and Enhanced 9-1-1 Programs, 2010). These elements are 
the data that show the most potential to improve emergency response and subsequently outcomes 
in severely injured crash patients (CDC, 2008). 


The recommended format for VEDS is XML, which is the most widely accepted format for 
exchanging structured data between different computer systems in the world today. It is an open, 
non-proprietary standard shared by all major software providers. However, VEDS is not a data 
transmission protocol/standard. How TSPs decide to send data, and how agencies collect data, 
transmit data, link it to voice, handle it within their various agencies, etc. are all critical issues, 
but not ones addressed by VEDS. Still, this common data set will enable multiple methods of 
data transfer and handling (Blincoe et al., 2002). 


The data elements in the Montana MVC Data Book were analyzed for common elements, 
disjunctions, and gaps in relation to the VEDS recommendations. See the description of the Data 
Book following the Summary section of this report. 


Next, data flow diagrams were developed to display visually where and of what type the data 
related to MVCs in Montana are generated, communicated, acted upon, archived, and reported 
on. An agency’s data diagram maps the movement of the data from initial collection through 
analysis, reporting, sharing, and then archiving. The data flow diagrams provide a visual 
representation of the Montana MVC data flow in relation to the timeline of the actual MVC 
event. Seven agencies’ data flow diagrams, developed in this project from key informant 
interview data, are show in Appendix B. 


2.3 Summary 


2.3.1 Before the 911 call 


Montana consumers have the option to purchase vehicles that are telematics equipped for 
automatic crash notification (ACN) or advanced automatic crash notification (AACN). Ifa 
consumer purchases a vehicle equipped with telematics, (s) he could subscribe to a telematics 
service provider (TSP), such as OnStar or ATX, which will provide the safety service the 
equipment permits. When consumers subscribe to a TSP, they give consent to the TSP to release 
their information to public safety agencies and to release their de-identified information for 
research purposes (Our Privacy Practices Notice of Privacy Statement, 2009). 


> A copy of the complete Data Book may be obtained from The Rural Institute on Disabilities, University of 
Montana, Missoula, MT 59812 or by calling (800)-732-0323 Voice/TTY Toll-Free 
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In the event of a crash, a telematics equipped and subscribed vehicle automatically initiates an 
emergency wireless call to a TSP to deliver the vehicle’s GPS location and crash-related data. 
ACN automatically sends information about airbag deployment and vehicle location to the TSP. 
AACN provides additional crash severity data generated from the in-vehicle telemetry, such as 
delta velocity, principle direction of force, and the number of impacts. The wireless call also 
opens voice communication between the occupants of the vehicle and the TSP advisor. 


In the event of a crash, if determined necessary through communication, or lack thereof, with the 
occupant(s) of the vehicle, the TSP advisor contacts the Public Safety Answering Point (PSAP) 
nearest to the crash. The TSP Advisor connects the occupant(s) of the vehicle to the PSAP Call 
Taker via a wireless three-way conference call. The wireless call is connected to the PSAP one 
of two ways: a standard 10 digit number or directly routed to the 911 trunk. If the PSAP has 
adequately sophisticated equipment and Memorandums of Agreement (MOA) with Enhanced 
911° (E911) service providers,° the TSP Advisor will connect directly to the 911 trunk and the 
call will come into the PSAP as a typical 911 call. If that equipment or MOAs are not in place, 
the call connects to the PSAP’s standard 10-digit phone number. The 10-digit number is 
typically connected to a non-priority desk. The dispatcher is mandated to answer all calls that 
come directly to the 911 line before answering calls on the 10-digit line. Electronic data cannot 
be delivered across the standard 10-digit phone line, so then the TSP Advisor relays crash data 
verbally in that situation. However, when calls are routed to 911 trunks they are formatted to 
forward the caller’s telephone number and location information with E911. This information 
automatically displays on the PSAP computer terminal at the time the call is received. 


Initially, all TSPs contacted PSAPs via the 10-digit number. However, TSPs are working through 
Qwest or CenturyTel and Intrado Inc. to route TSP calls directly to the nearest PSAP on the 911 
trunk. Qwest and CenturyTel are responsible for aggregating and routing emergency calls to the 
appropriate PSAP based on the county of jurisdiction of the 911 caller’s address or location. 
Intrado Inc. is a third party database manager that provides E911 database management services 
for Qwest and CenturyTel. The E911 database contains end-user information (including name, 
address, telephone number, and occasionally special information from the local service provider 
or end-user) used to determine routing the call to the appropriate PSAP and provide the location 
information (Quest Communications International Inc., 2010). 


While Intrado Inc. currently provides for automatic number identification (ANI) and automatic 
location information (ALI) to most Montana PSAPs, they can also provide for the transport, 
transmission, and routing of additional data from emergency telecommunications services, such 
as AACN data (Intrado Communications Inc, 2010). ° Each PSAP has the decision-making 


“Enhanced 911 is a telecommunications based system that automatically associates a caller’s telephone number 
(automatic number identification (ANID) and location information (automatic location information (ALI)) and 
forwards the call and information to the PSAP nearest the caller. http://www.qwest.com/wholesale/pcat/911.html 


> Enhanced 911 Service Providers include: Basic 911 Service Providers (Qwest or CenturyTel in Montana), and a 
third-party Enhanced 911 database manager (Intrado Inc., 2010) 


. Ryan Olson (Montana Department of Administration 911 Program), discussion with authors, 2010. The business 
relationships between local PSAPs, Qwest or CenturyTel, and Intrado vary based on whether the PSAP’s 9-1-1 
service is through Qwest or CenturyTel. Approximately half Montana PSAPs are Qwest and half are CenturyTel. 
PSAPs with Qwest typically have more unique systems, whereas PSAPs with CenturyTel are more standardized 
systems. CenturyTel’s more standardized system makes them a good starting point for testing/piloting projects. 
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authority and liability to accept what, if any, ACN/AACN data will automatically display on 
their computer.’ As of March 2010, no Montana PSAP receives additional TSP data via their 911 
trunk. 


The Missoula PSAP was recommended for interview for this report by the State 911 Program 
office as one of the most advanced call centers in Montana. As other Montana PSAPs update 
their systems, they are likely to develop their infrastructure as Missoula has. Each PSAP is 
unique in when, what, how, and why they gather MVC data. Still, networking between PSAPs 
occurs at statewide PSAP manager meetings that occur at least bi-annually. When available, 
examples of how Montana PSAPs vary are provided in this report. 


In Missoula, TSP calls come directly in on the 911 line; however, ANI/ALI information is the 
only ACN data that automatically displays on their computer terminal. The process for adding or 
making changes to capture ACN/AACN data would be fairly simple. No new technology would 
be necessary to take additional TSP data directly onto their ANI/ALI screen. They would follow 
the same process they currently use to add a new cell phone company. The PSAP would map the 
data and possibly modify the current database to accommodate the field sizes required for the 
TSP data. Training time would be required for the new elements. 


Because the 54 PSAPs operate independently, the process of bringing telematics services to 
Montana involves multiple partners, agreements, and local initiatives. For the Missoula PSAP, 
authority to make changes to 911 data comes from the 911 center’s manager and the local 911 
Advisory Board, which is comprised of the County Sheriff, the Police Chief, a citizen member 
appointed by the County Commissioner, the County Disaster and Emergency Services 
Coordinator, representatives from the County Fire Protection Agency (city and rural), and a 
representative of Ambulance Services. 


The Missoula PSAP is in the process of developing a six-year strategic plan that will encompass 
ways to take data from various telecommunication devices that would enhance public safety 
communication. For example, they are considering how to receive cell phone pictures and videos 
taken at the site of the emergency from victims, witnesses, or ERs. Strategic planning is more 
difficult for smaller Montana PSAPs due to time and funding. 


There are no specific data formatting requirements. Missoula would like to use the JDXML, or 
the Justice Department’s XML, format for data recording and storage. All the PSAPs and the 
ERs have access to the JOXML formatting, which is based on law enforcement or fire/medical 
tags. It is widely accepted as a good idea to use the JOXML format data, but it is not widely used 
at this time. The Missoula PSAP personnel have not found a vendor that can integrate data from 
JDXML, which is considered a competing software network. 


2.3.2 During the 911 Call 


In Missoula, when a call is initiated, the PSAP call taker immediately begins collecting MVC 
data into their computer aided dispatch (CAD) system via the PSAP’s computer and phone 
systems. The phone system includes the Voice Over Internet Protocol (VOIP), which permits the 
ANI/ALI information. The ANI/ALI information is sent directly into their CAD system. The 


’ There are 54 PSAPs in Montana. Many of these PSAPs have a single county jurisdiction. Some have city 
jurisdiction that represent multiple counties. 
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CAD generates correct recommendations as to which emergency responders should be 
dispatched. 


Much of the operational procedures of PSAPs are a function of the software and the call-taking 
equipment, which varies because they are supplied by many different CAD vendors. Both 
Missoula and Lewis and Clark, two of the larger PSAPs, use Logistics Systems Inc., which is a 
Tier One systems provider (Logistics System Inc., 2008). 


There are no legal or regulatory requirements for MVC data gathered by Montana PSAPs. The 
data collected by PSAPs are primarily data requested by dispatch agencies as opposed to any 
state reporting requirements. The dispatch agencies themselves may have state requirements for 
and agreements with local PSAPs to provide the data. The core information collected by PSAPs 
that is common across Montana PSAPs includes: 

e The nature of the incident (i.e., injury accident, non-injury accident, moving violation, 
burglary, etc.) 
Incident location information® 
The caller’s name 
Re-contact address 

e Callback phone number 
These core data have their own fields on the information screens of the computer terminals and 
in archival databases. Other information, such as the nature of injuries, is entered into a comment 
field on the information screen. The comment field provides call takers with an unlimited ability 
to ask questions and put more information into the system for immediate use.” 


According to the Montana Constitution, information from 911 emergency calls is part of the 
public record. However, the privacy of criminal justice information about persons involved in the 
incident or MVA is protected by state statute and national laws. The PSAP redacts criminal 
justice information such as driver’s license and license plate numbers from data that are provided 
to any non-law enforcement agency, including fire and medical agencies. Any health information 
contained in the PSAP’s call records is not protected by HIPAA since 911 centers do not provide 
direct hands-on patient care. Still, there is a generic protection because no name is ever linked to 
a specific injury. A patient’s name is never provided over the air to responders and any 
information responders provide back to the PSAP during the call is simply sex, general age, and 
the extent of their injuries. 


2.3.3 Dispatch 


For Missoula County, all injury motor vehicle crashes receive the same level of response, which 
is considered Advanced Life Support (ALS) medical. While technically a tiered emergency 


* Location information displays with the class of service. The class of service tells the Call Taker and Dispatchers 
whether the latitude and longitude provided come from the closest cellular tower to the caller, the location of the 
actual caller if the caller is using a cell phone, or the location of a landline telephone. Location information from 
cellular calls also comes with a certainty factor. The certainty factor uses data from a triangulation of three towers to 
estimate how accurate the latitude and longitude are. However, accurate latitude and longitude of the actual caller 
are not always possible in rural Montana because there are not always three cellular towers with which to triangulate 
of the call. Therefore, Montana PSAPs rely heavily on voice communication for accurate location information. 


* It is difficult to search information listed in the comment section. 
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medical response exists, the Missoula PSAP errs on the side of caution and sends a full 
emergency response. Missoula is an Emergency Medical Dispatch (EMD) 911 center. EMD 
protocols help determine whether an incident requires basic EMS, ALS EMS, air medical, and/or 
fire department response. Only five or six Montana PSAPs provide EMD. PSAPs that adopt 
EMD typically err on the side of caution and send more emergency responders than may be 
necessary based on the nature of the incident rather than the confirmation of injury by the caller, 
a witness, or a first responder. PSAPs that have not adopted EMD often wait to dispatch 
responders until an injury is confirmed. 


Association of Public Communication Officers (APCO) provides the protocols for EMD in 
Missoula. The Montana chapter of APCO holds statewide meetings approximately every three 
months at locations around the state. APCO protocols are currently listed on flip cards located on 
the PSAP Call Taker’s workstation. When the call taker determines the nature of the incident 
(s)he flips to the corresponding APCO protocol and proceeds as directed. ' 


Most PSAPs in Montana have one person designated to receive and respond to 911 callers. If 
there is more than one person, the job is typically split into a call taker, who receives the call, and 
the dispatcher(s), who coordinate the dispatch of emergency responders. The call taker’s job is to 
enter core information into the CAD system. In Missoula, there are three dispatch positions: 1) 
fire/medical and administrative line dispatch, 2) county sheriff law enforcement dispatch and 
intermediary Montana Highway Patrol, and 3) city police law enforcement dispatch. Depending 
on the time of day, there is additional staff for back up.'' When the call taker enters the nature 
and location of the incident, the CAD system automatically notifies the dispatchers. In Missoula 
they strive to send core information to the rest of the room in under a minute. 


PSAPs directly dispatch fire, medical, local police and sheriff department responders. Call for 
service information is relayed verbally by the PSAP dispatchers or electronically by the CAD 
system to the responding agencies. The call for service information includes: 

Call location, 

Call type, 

Comments, and 

Other dispatch agencies that are being recommended 


The fire and medical dispatcher selects the voice tones for the voice paging system. These tones 
open the radio channel where they verbally announce the call for service information. In 
Missoula, call for service information is also automatically sent by the PSAP CAD system to 
“rip-and-run” printers located at the fire station and the ambulance company. 


In Missoula, the CAD system recommends a law enforcement unit to respond. The law 
enforcement dispatcher selects the recommended unit or chooses a different unit if warranted. 
The dispatcher verbally relays the call for service information to the responding unit via the 
radio. The county police and sheriff departments are on the same county computer network as 
the PSAP, so call for service data is automatically sent to the responding unit’s mobile terminal 
where the data populates the MVC reports. 


'° The Missoula PSAP, as of April 2010, is integrating the EMD information from the flip cards directly into their 
CAD system. 
'' In smaller Montana PSAPs there typically is only one person that is the call taker and the dispatcher. 
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An air medical response 1s initiated based on the location and nature of the incident. Voice and 
digital pagers notify air medical immediately. The Missoula PSAP does not wait for notification 
by a responder on the scene to dispatch air medical due to warm-up time for the helicopter. In 
Missoula, air medical dispatch works on a rotating basis. On odd days, St. Patrick Hospital’s Life 
Flight helicopter is dispatched in the event of an advanced life support emergency that occurs in 
the geographic area that they cover. On even days, Community Hospital’s Care Flight helicopter 
is dispatched. 


The PSAP dispatcher indirectly dispatches the Montana Highway Patrol through the Highway 
Patrol’s dispatch center. The PSAP also indirectly dispatches tribal emergency services through 
tribal services. The PSAP dispatcher verbally relays call for service information via the phone or 
transfers the 911 caller directly to the dispatcher at the other agency. 


The Missoula PSAP also has CAD Status, software that allows any agency dispatched by the 
PSAP to view emergency calls in live time as the incident is occurring. CAD Status can be 
installed on any computer that supports JAVA and has high-speed internet access. The software 
automatically updates every 30 seconds. If an agency is connected to CAD Status, they have the 
ability to print the call for service data as it is ongoing. 


From the time, the PSAP notifies each agency until the agency is actually en route varies. 
Volunteer agencies staffed with volunteers who may have to leave other jobs to respond to an 
emergency may have a guideline to strive for five to ten minutes, whereas a paid agency with 
dedicated emergency response staff may strive for a minute. Once agencies are dispatched, the 
PSAP collects time information. Time information includes: 

e Time dispatched, 
Time in route, 
Time on scene, 
Time they leave the scene, and 
Time they are headed to the hospital, or 
Time they become available to respond to another call. 


2.3.4 Emergency Medical Services (EMS) 


EMS and fire departments print and manually enter the call for service data into their electronic 
reporting systems. '* There is a lot of variability in the software and equipment used by each 
EMS provider because each has decision-making authority and liability. Still, all Montana EMS 
providers are licensed by the Montana Department of Public Health and Human Services’ 
(DPHHS) EMS and Trauma Systems Section. As a licensing agency, DPHHS sets basic data 
collection requirements, and they encourage and guide best practices. 


The Montana EMS and Trauma Systems Section encourages EMS providers to take advantage of 
anew, custom, license-free data collection and compilation software package, Online Prehospital 
Information—Patient Care Record (OPHI-PCR). The DPHHS EMS office developed OPHI- 
PCR. It is a cost effective, efficient performance improvement tool that is accessed online. 
“OPHI enables EMS services to electronically collect patient care information. Not only useful 
for documentation of patient care, this module will ultimately meet essential needs for service 


"Chris Lounsbury (Missoula PSAP), discussion with authors, 2010. In Missoula, interfaces between software used 
by fire and medical agencies and the PSAP CAD vendor do exist, but are not utilized. An interface would enable 
electronic transmission of the data and eliminate the dual manual entry of the same data. 
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evaluation and performance improvement.” (Montana DPHHS, 2010) The license-free nature of 
the software enables the state EMS and Trauma Systems Section to update data fields for data 
collection as needed without vendors’ proprietary challenges. 


The data elements included in the OPHI-PCR software is National Emergency Medical Services 
Information System (NEMSIS) compliant. The NEMSIS database is widely accepted among 
states and vendors as the gold standard for EMS data. The entire NEMSIS database is around 
400 data elements. OPHI-PCR includes a subset of these data elements. Of the elements in the 
OPHI-PCR, the state aims to direct EMS providers to report a minimum dataset of about 70 
NEMSIS data elements to a state database. '* These data will primarily include: 

Time information 

Demographics of a patient 

Location of the incident 

Location the patient to which the patient is transported 

Status of the patient 


The OPHI-PCR software includes a comprehensive reporting package that can be utilized as a 
performance improvement tool. The reporting package allows EMS providers to track their own 
performance and make comparisons to the performance of other anonymous EMS providers. 
Performance improvement is an incentive for EMS providers to utilize the OPHI-PCR software 
to collect and report data. As more providers use OPHI-PCR, the Montana EMS database 
receives data from a larger percentage of EMS providers. Eventually Montana will push EMS 
data to a national dataset. Currently 30 out of the 250 Montana EMS providers use OPHI-PCR. 
Many more are expected to use OPHI-PCR as they recognize the many benefits it offers. 


2.3.5 Police and Sheriff 


In Missoula, local law enforcement personnel open the MVC report with pre-populated crash 
data from the PSAP on the mobile computer terminal located in their vehicle. The local law 
enforcement emergency responder enters additional crash data at the scene of the crash via the 
mobile computer, or via computers located at their departments after the crash is cleared. 


MVC reports are each given a unique incident code used to access the report. The incident code 
is automatically generated based on the nature of the incident. Additional MVC data can be 
added to the electronic MVC reports as needed. Some Montana local law enforcement agencies 
do not have electronic MVC reports. These local agencies record MVC data on paper MVC 
reports provided by the state at the scene of the crash, or soon after the crash. 


All paper and electronic MVC reports are submitted to the Montana Highway Patrol for MVC 
investigation. If there is a criminal aspect of the MVC, the local law enforcement agency also 
investigates the incident. The MT Highway Patrol is currently developing a web-based version of 
the MT MVC report for all Montana police and sheriff departments to access from any computer 
with internet access. The web-based MVC reports will automatically be entered in the Highway 
Patrol’s server upon submission. While paper MVC report forms may still be used to gather 
crash data at the scene of the crash, the web-based MVC report will eliminate paper submission 
of MVC reports to the Highway Patrol. 


'’ This change in reporting requirements will require a change in policy. The Montana EMS and Trauma Systems 
Section is in the process of making this change 
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2.3.6 Highway Patrol 


The PSAP verbally relays call for service information to the Montana Highway Patrol dispatcher. 
The Highway Patrol dispatch center currently does not receive data through the phone system, 
where data (i.e., ANI/ALI) would display on the computer screen when the call is answered. 
However, they are working with the State 911 Program to become equipped to receive call data 
directly through the phone system. The most important MVC data for Highway Patrol from the 
PSAP are: 

e Exact location 

e Injury 

e Traffic blockages 


The Highway Patrol dispatcher immediately inputs the data into the statewide Highway Patrol 
smartCAD system. Features of the smartCAD system include: * 
e Miulti-agency system 
Unlimited 911/E911 PSAP interfaces 
Integrated mapping and GEO-location for all calls 
Unlimited agencies with tracking for unique agency report numbers 
Synchronized real-time CAD (Call and Unit) status on all mobile computers 
911 system interface 
911 wireless phase II ready 
Station alarm interface and call faxing 
AVL plotting and tracking 
Immediate update to workstations on call assignment or status change 
Integrated NCIC/State interface 
Configurable run cards for LE, Fire and EMS 
Color-codes calls by priority as defined by the agency 
Automatic GEO file validation of addresses 
Dispatcher notification of Be on the Lookout (BOLO), caution notes, and vehicle 
history 
e Captures and stores demographic data for identification and prevention of racial 
profiling 
e Integration with other SmartCOP modules 
e Configuration allowing for agency-specified complaint types, disposition codes, 
quick-keys, and call/unit priority colors 
Transmission of BOLOs to MCT 
Customizable views of specific zones or an entire district 
Tracking of assigned and unassigned officers 
Apparatus recommendations based on status, location and other definable properties 


The Montana Highway Patrol smartCAD automatically updates a public website’’ with traffic 
incident information (MT Department of Justice, 2010). The website displays a statewide map 


'4 For more information about smartCAD features visit http://www.cts-america.com/smartcad.asp#Overview 
'S http://doj.mt.gov/enforcement/highwaypatrol/incidents/default.asp 
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marked with the approximate location of recent MVCs reported by the MT Highway Patrol. The 
website also displays a table that lists: 
e Incident number 
Date 
Dispatch time 
Arrival time 
Incident type 
Location 
Remarks 


Current MVC information is available on the live map for approximately 2 hours. Anyone can 
search the website for traffic incidents based on time or location of the incident within the last 10 
days. The same information displays on the screen, the only difference is the displayed map is 
not in “live time”. 


The Highway Patrol dispatcher assigns a trooper to respond to an incident via radio, or troopers 
actively scan for MVCs in their area on the trooper’s mobile computer terminal and mark 
themselves in route. 


Troopers collect MVC data using the SmartCOP software, the crash module. The SmartCOP 
crash module is 100% Model Minimum Uniform Crash Criteria (MMUCC) compliant. MMUCC 
is a voluntary guideline that helps states collect consistent crash data for a wide range of traffic 
safety planning applications (MMUCC, 2008). The crash module contains edit rules that force 
troopers to enter required data. '° The module also allows for any additional data (i.e. video, 
pictures) to electronically be attached to the MVC report. 


Troopers are trained to open the crash module on the mobile computer terminal and 
electronically save the GPS of the vehicle location immediately upon arrival at the scene of a 
MVC. The majority of the crash report is filled in at the scene of the crash using the mobile data 
computers. However, troopers can recall crash reports from the mobile computers or on a PC at 
the station to enter additional MVC data. Crash reports can be printed in the vehicles. Troopers 
complete the crash investigation which, depending on the type of crash, could take minutes or 
days. Typically they try to have a five day limit on all crashes with the exception of fatalities, 
where there is a 30 day limit. When the MVC investigation is complete, the trooper gives it to 
his/her sergeant for approval and electronic submission. 


Crash reports are compiled in Microsoft SQL and Crystal Reports. Crash reports are routinely 
digitally reported to the Montana Department of Transportation. Summary reports can be 
generated by the MT Highway Patrol for a specific location or area for a specified time period 
(i.e., hourly, daily, weekly, or monthly). The MT Highway Patrol can provide individual reports 
with date, time, location, and injury information including severity without identifiers. 
Individuals involved in MVCs can obtain a complete crash report by providing appropriate 


'© Changes to the data collected by the crash module would need to be approved by the Major. The approval process 
includes verifying compliance with state laws, availability of technology, MMUCC compliance, and a cost benefit 
analysis. The Highway Patrol system has the necessary technology to make data changes in their collection system. 
The major challenges of making changes to their system are cost and personal rights when sharing the data. 
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identification. Insurance companies can also obtain crash reports with a signed release form from 
the individual(s) involved in the MVC. 


2.3.7 Tribal Services17 


Ifa MVC occurs on one of the seven reservations in Montana, which represents 6% of 
Montana’s population, the PSAP dispatches Montana Highway Patrol and contacts the tribal law 
enforcement by phone. Tribal emergency response centers are not networked into the 911 
system. The centers are connected to a standard 10-digit telephone number. Each of the seven 
federally recognized Tribes in Montana is its own sovereign nation, so each has its own law 
enforcement and emergency response system. '* 


MVC response is immediately more difficult on reservations because identifying a specific 
location is difficult. The Montana Highway Patrol does not recognize all the road systems on 
reservations and mile markers are sometimes missing. Also, cellular coverage is very limited on 
reservations. 


Once at the scene of the crash, Highway Patrol and Tribal Law Enforcement coordinate and 
determine jurisdictional authority. If a non-tribal member is involved in the MVC, then the 
Highway Patrol reports the MVC. If all individuals involved in the MVC are tribal members, 
then Tribal Law Enforcement reports the crash. Sometimes MVCs are reported by both Highway 
Patrol and Tribal Law Enforcement. A 2008 Montana Tribal MVC study found that between 10- 
20% of tribal data was not accounted for in Highway Patrol data’’. To get the most complete 
MVC data from reservations, it is important to review both sources. 


The collection, compilation, and utilization of MVC data are unique to each tribe. Each reporting 
system is completely separate from the state and each other. The Crow Agency partnered with 
the state to develop a software system to enter tribal MVC data. The system was developed by 
Creative Information Systems Company (CISCO), a networking and communications technology 
and services provider (CISCO, 2010). However, the CISCO software is not being used due to the 
lack of training, not enough personnel, or inadequate equipment. 


Tribal MVC data are primarily collected on paper forms. However, filling out and compiling 
MVC reports are not consistent. Tribal MVC data are archived after 3 years at the Bureau of 
Indian Affairs in Albuquerque, New Mexico. Tribes do not report MVC data to the Montana 
Department of Transportation. 


Fire and medical emergency responders are dispatched from the PSAP or the tribal emergency 
response center based on location. The Indian Health Service hospitals will provide emergency 
care for non-tribal injured individuals. Likewise, non-Tribal hospitals will provide care to injured 
Tribal members. 


'7 For more information about tribal emergency response visit 


http://www.ihs.gov/MedicalPrograms/InjuryPrevention/Documents/BIAFY 08HSP.pdf 
http://www.indiantech.org/ 


'S To incorporate ACN/AACN data into the Tribal emergency response system contact the Montana Wyoming 
Tribal Leaders Council. More information about the Council can be found at http://www.mtwytlc.com/ 
Me Darcy Merchant interview by authors, August 19, 2009. 
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2.4 After the 9-1-1 call 


2.4.1 Reports 


PSAPs collect time data until injured individuals are transferred to the hospital, or the scene of 
the crash is cleared. The Missoula PSAP’s policy is to transmit the completed call for service 
data to emergency responding agencies as soon as the last fire or medical unit clears the call. The 
call for service at the end of the call contains location, nature of the incident, comments, and time 
information. The PSAP sends the data electronically to a printer located at the EMS and a printer 
located at fire departments. 


PSAPs are the source of data used in routine reports that are requested by direct dispatch 
agencies. Other affiliated agencies, such as Highway Patrol, can request copies of call 
documentation for their reports. The PSAP typically faxes a printout of the call for service 
record. Finally, researchers or the public can request a print call for service record through the 
County Attorney’s office. 


2.4.2 Archive 


The length of time that a PSAP retains a data record for each call is unique to each PSAP. Some 
keep audio recordings for two years, other PSAPs that do not have a lot of memory on their 
voice recorder might go a month and then delete it. Some digitize their voice records and some 
print out their call details and store them on a shelf. Some PSAPs might not even be able to print 
out call details.”” The Missoula PSAP’s active data goes back to 2000. This active data can be 
accessed directly at the center. Any records prior to 2000 can be pulled out of archives. Call 
records are tracked by complainant name, location, and the incident code. 


After the 911 call, MVC data continue to being collected by hospitals. Hospital records and the 
Montana Trauma Registry capture the most complete picture of the extent of MVC injury 
outcomes. Hospital and Trauma data also capture MVC data from injured individuals involved in 
MVCs that do not activate the 911 system. However, hospital data are protected by privacy laws 
so are difficult to access. 


2.5 Hospital Data 


2.5.1 Hospital Emergency Department 


Pre-hospital MVC data are given by EMS providers to the hospital in print form and verbally 
relayed. In some hospitals, EMS personnel enter pre-hospital data into a computer dedicated for 
EMS use at the hospital. These data are recorded with the patient care record of an injured 
individual. 


The Montana Hospital Emergency Department (ED) and Discharge Dataset is currently owned 
by the Montana Hospital Association. Currently about 10% of hospitals in Montana voluntarily 
submit data to the dataset. While legislation that would mandate reporting of hospital ED and 
discharge data to a state database did not pass at the last session, funding for the dataset was 


°° One common point for the data storage may be Intrado. If a wireless caller gets dropped and the PSAP doesn’t 
have the technology to bring up the old records and start troubleshooting, they can get information from Intrado, 
which keeps a record of the data that routed through them. 
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approved. Thus, the state DPHHS is in the process of increasing the amount of voluntary 
reporting. The dataset currently does not connect any injuries to MVCs. 


Confidentiality and privacy of both patients and hospitals are strongly protected by law. 
2.5.2 Trauma Registry 


The most complete injury outcome dataset in Montana is the Montana Trauma Registry.” 
However, the trauma registry collects information from only a subset of trauma patients. This 
subset is comprised of patients with the most severe injuries by any fashion—this includes the 
most severe injuries sustained from MVCs. Patients with severe injuries are those who need 
surgery, stay more than three days in the hospital, or die. 


If a person is injured in a MVC and taken to an American College of Surgeons (ACS) certified 
hospital, trauma data are entered into the Trauma Registry directly via Collector software. 
Trauma coordinators typically enter the data on a routine basis (i.e., daily, weekly, etc.). In large 
Montana hospitals, such as Billings or Great Falls, trauma data are submitted continuously as 
trauma incidents occur. In smaller hospitals trauma data are submitted at least quarterly. 


Trauma data from large Montana trauma hospitals are generally more detailed because they 
typically have patients for longer periods of time, do more tests and procedures, and know more 
about outcomes of patients. Smaller hospitals that are not ACS certified mail a paper form with 
trauma information to the state’s EMS and Trauma Systems Section where it is manually entered 
into the Registry. These data are generally less detailed as patients are usually transferred from 
the smaller hospitals to larger trauma hospitals. 


The state Trauma Registry is currently moving to a web-based system that enables all hospitals 
with internet access to submit their own trauma data. The web-based system will eliminate paper 
submissions of trauma data to the EMS and Trauma Systems Section. It will be more time and 
resource efficient. The web-based system will also improve the quality of the data being 
submitted, as Collector automatically validates the data. 


The Trauma Registry is a high end performance improvement tool for trauma hospitals. 
Collector has a comprehensive reporting package that makes it easy for hospitals to track their 
own performance and compare themselves to the performance of other hospitals. Still, the 
registry is strongly protected by state statute and is proprietary. While hospitals have unlimited 
access to their own individual and compiled data, they only have access to statistical non hospital 
specific data that are submitted by other hospitals. For example, a reporting hospital can compare 
their own trauma data to data from a similar sized hospital, or to data from the same state or 
region, etc. The internal performance design coupled with a strong protection of the data 
provides hospitals will a good incentive to report and utilize trauma registry data. As a result, 
90% of the 56 hospitals in Montana routinely submit trauma data. 


There is no standard nationwide trauma dataset. However, most trauma registries around the 
country use Digital Innovations’ Collector software, so the data are somewhat standardized. 
There is also a national trauma databank owned by the ACS that gathers the somewhat 
standardized data. The state EMS and Trauma Systems Section sends Montana trauma data 


*! The trauma registry would be the best indicator of whether ACN data are accurate for severe injury predictions in 
Montana. 
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gathered in Collector to the national databank. Montana trauma data are compared to national 
data and summary reports are sent back to each hospital on a routine basis. 


Trauma registry data are used in policy decision-making or for specific preventable death 
studies. These data are strongly protected, so studies are typically internal.”” Montana trauma 
data are reviewed at the Regional Trauma Advisory Council (RTAC) quarterly meetings to 
confirm validity and develop action plans. 


2.6 Data Book 


The Montana MVC Data Book (Appendix C) is a resource developed by the Task 1 project team 
of Amanda Golbeck, Kathy Humphries, and Julie Stevens. It contains specific MVC data 
element information from MVC crash databases in Montana. 


The Book is an EXCEL workbook. Each agency that collects MVC data in Montana has a 
separate worksheet in the workbook that lists the MVC data elements collected by that agency. 
The information in the Book was abstracted from data dictionaries provided by each agency and 
verified by appropriate professionals representing each agency. 


The Book contains a summary worksheet, labeled ‘SUMMARY’. The SUMMARY worksheet, 
which is the first worksheet in the Book, cross-references the Montana MVC data elements and 
the VEDS- recommended data elements. The SUMMARY worksheet may be used to identify: 


e Useful and critical crash elements currently being collected in Montana, and 


e Useful and critical crash elements not currently being collected in Montana. 


VEDS data elements are given in the first two columns of the SUMMARY worksheet. The 
VEDS elements are grouped according to category, which is listed in column 1. The categories 
are highlighted in the row directly above the group of elements falling within that category, 
which are listed in column 2. For example, ‘latitude’ in column 2, row 17 refers to the latitude of 
the incident because it is listed under the highlighted ‘Incident Data’ category in column 1. The 
rest of the columns (columns 3 and higher) in the SUMMARY worksheet correspond to the 
agencies collecting MVC data. 


The entry that falls within the intersection of a row and column in the SUMMARY worksheet 
indicates where the VEDS data element indicated by that row is found on the agency worksheet 
indicated by that column. For example, row 17 represents latitude of the incident, and column C 
represents OnStar. A‘12’ in row 17/column C indicates that the OnStar entry for latitude of the 
incident is found in row 12 of the OnStar worksheet. A blank in row 17/column C indicates that 
OnStar does not collect data on latitude of the incident. In this way, each row identifies all 
Montana MVC agencies that provide a given VEDS data element, specifying where to find that 
element within each of the agency worksheets. 


In addition to the SUMMARY worksheet, each agency worksheet contains a ‘VEDS Element’ 
column that identifies the VEDS data element that corresponds with the MVC data element listed 


*° For example, information about the severity of injury and seatbelts was researched to provide evidence for 
Montana seatbelt legislation. In terms of this project, in order to honor the restrictions on trauma registry data it 
would be easier to look at how the state could warehouse some of the ACN data internally and research injury 
prediction internally vs. sending the data elsewhere. 
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in each row. For example, row 23 of the “MSO 911’ worksheet identifies the data element for the 
address of the incident. The address of the incident corresponds to VEDS data elements: incident 
location, incident latitude, incident longitude, and incident location description. 


2.6.1 Flow Diagrams 


Data flow diagrams have been developed to display visually the data processes related to motor 
vehicle crashes (MVC) in Montana: How data are generated, communicated, acted upon, 
archived, and reported. An agency’s data flow diagram maps the movement of the data from 
initial collection through analysis, reporting, sharing, and then archiving. The data flow diagrams 
provide a visual representation of the Montana MVC data flow in relation to the timeline of the 
actual MVC event. Seven agencies’ data flow diagrams were developed in this project from key 
informant interviews. 


2.7 Comments 


One concern voiced about ACN’s owner medical history data is that you never know who’s 
actually going to be in the vehicle. Still, in Missoula, Missoula Aging Services gathers voluntary 
medical information from the disabled and elderly to share with the PSAP. This information is 
entered into their CAD system so if an emergency call comes from that number or residence it 
automatically notifies the call taker that the incident may involve people with disabilities or 
special medical conditions. This information is useful information for hospitals or medical 
responders for what they might expect upon arrival. 


A/ACN data would be beneficial for more efficient location identification and more accurate 
historical vehicle data. The telemetry data reported from the car would be helpful in MVC 
investigations. Finally, linking data from the beginning of the MVC clear through the long-term 
injury outcomes of individuals involved in the MVC would be helpful for policy decision- 
making, such as seat belt legislation. 


2.8 Recommendations 


Four recommendations come from this task. First, in Montana, agencies or parties either 
individually or collectively contribute to MVC data infrastructure, but not in a highly connected 
way. Steps toward a more cohesive infrastructure will permit a more comprehensive integrated 
motor vehicle crash-related data system for Montana that includes A/ACN. Employing these data 
can potentially increase the integration and effectiveness of the response and rehabilitation 
systems. 


Second, most of the agencies appear to be in a transitional state with MVC data. EMS is rolling 
out OPHI-PCR. Highway Patrol recently started using only the SmartCOP Crash module and is 
developing a web-based version for access by all law enforcement personnel. Highway Patrol is 
also working to update their dispatch center to begin taking data directly into their system. The 
hospital ED and discharge database is still being developed. These transitions provide an 
opportunity for integrating A/ACN data into the Montana MVC data infrastructure. For example, 
one barrier identified by interviewees was training staff to effectively use new data. Perhaps any 
additional training needed for ACN data could be rolled into the training that will occur with 
these transitions that are already in progress. 


Third, most of the agencies already collect data elements that could be useful for linking across 
databases. These data elements include: the date, time, and latitude and longitude of the incident. 
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The data dictionary locations are show below. The Data Book worksheet is identified in bold 
with the row number of the data elements for potential linking in parentheses. 


= OnStar (10-13) 

" MSO 9-1-1 (433, 55, 23) 

= EMS OPHI-PCR (143, 140, 218) 

= Police and Sheriff (5-7, 81-83) 

" Highway Patrol SmartCop Crash (4, 17-18) 
= Trauma (62,”° 63) 


The only agency that does not have data identified as MVC data is the Hospital ED and 
Discharge dataset. 


Finally, Intrado, the data service provider for the PSAPs, may work with the Montana Highway 
Patrol dispatch center to send additional TSP data directly to their future ANI/ALI screens. It 
may be possible for the TSP to send the same MVC data simultaneously to the PSAP and the 
Highway Patrol. For PSAPs that do not adopt EMD and wait for an officer at the scene to 
confirm an injury before sending fire/medical responders, this could decrease response time. 


°° Place of injury, which may or may not contain latitude and longitude 
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3 Pathways and Support for Delivery of Crash Telemetry Data to 
PSAPS and EMS 


Now is a particularly important and appropriate time for Montana to undertake the development 
of a detailed plan for upgrading the crash-related data infrastructure and demonstrating its utility. 
As noted previously in Chapter 1, the national trauma triage guidelines have recently been 
amended by the American College of Surgeons and the CDC to include the consideration of 
‘vehicle telemetry data consistent with high risk of injury’ as a criterion for making the decision 
to transport an injured victim to a trauma center (CDC, 2009). Furthermore, a national Technical 
Panel convened by the CDC, made up of representatives from 9-1-1 call centers, EMS, 
emergency medicine, trauma surgery, engineering, public health, vehicle telematics providers, 
NHTSA, and an EMS for children program, recommended vehicle telemetry data be used to 
assist the dispatch of appropriate emergency services to crashes (CDC,2008). They concluded 
AACN shows promise in improving outcomes in severely injured crash patients by: 

e Predicting the likelihood of serious injury in vehicle occupants 
Decreasing response times by pre-hospital care providers 
Assisting with field triage destination and transport decisions 
Decreasing time to definitive trauma care 
Decreasing death and disability from motor vehicle crashes 


The planning for this data infrastructure upgrade is also timely, given the Next Generation 9-1-1 
(NG 9-1-1) program is developing technology that will allow call takers and dispatchers at 9-1-1 
Centers to send and receive data, digital pictures and video, email and text messages, and other 
modern communications from computers and handheld devices instead of relying solely on the 
traditional 9-1-1 voice-only telephone calls. This technology will greatly facilitate the delivery of 
vehicle crash telemetry data to the appropriate 9-1-1 PSAPs. It is of interest to note Helena, MT 
was one of five PSAPs selected to test a NG 9-1-1 network prototype design (USDOT, 2009). 


As Chapter | illustrated, there are a variety of traditional data sources for near-real time crash 
and crash-related injury data. These include 9-1-1 PSAPs, police agencies, EMS, and hospital 
emergency departments. The purpose of this task was to identify and demonstrate how — using 
currently available technology - AACN telemetry information can be acquired and shared with 
responders in real time, as well as archived for post event use and future inclusion in Montana’s 
upgraded crash data infrastructure. 


3.1 Background 


Before describing the methods used to provide crash telemetry data to emergency providers, it is 
necessary to provide relevant background information on the Advanced Automatic Crash 
Notification (AACN), as well as a brief description of the injury prediction algorithms that use 
this data. 


Figure 6 summarizes the vehicle based AACN data available for transfer to a PSAP and EMS. 
These data include crash location, crash delta velocity, direction of impact, whether airbag 
deployed or a rollover occurred, and whether there were multiple impacts. The items in bold 
italic font are fields that are typically not included in an AACN transmittal to an outside agency 
but are available to the Telematics Service Provider (TSP). The vehicle data captured by AACN 
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systems, coupled with occupant data (that may be obtained verbally by emergency call takers 
like gender and occupant age) and other available data such as vehicle make/model and weight, 
are being used to predict the probable injury severity sustained by crash vehicle occupants. 
Because they use data transmitted from the car at the time of the crash, the injury severity 
prediction is usually available to EMS before anyone arrives at the crash scene. 


What is AACN? 


«in-vehicle instrumentation that can: 
1) Sense when an above threshold crash has occurred 


2) Collect real-time data from the vehicle to characterize the crash 
* Crash Delta Velocity 
* Crash Location (fromGPS) 
* Air bag deployment 
* Occupant restraint use 
* Occurrence of multiple impacts 
* Occurrence of rol-over 
* Vehicle final resting position 
* Direction of impact (frontal, driver side, etc.) 


3) Automatically assemble and transmit a message (via cellular system) with crash 
related information 


+ External components that can: 
1) Receive crash message and verify emergency exists (usually by a Telematics 
Service Provider) 
2) Relay information to appropriate public safety (9-1-1) agency 


Figure 6. In-vehicle and external components of AACN system 


Information on the severity of injuries, if provided to dispatchers and responders when first 
notified, could guide decisions regarding the type of resources to deploy (e.g., should air medical 
and trauma center be notified), as well as indicate the need for speed in the response (i.e., are 
lights and sirens really necessary?) (CDC, 2009). 


Translating crash telemetry data into physical forces experienced by an occupant in a crash and 
subsequent estimation of an injury severity score requires an injury prediction algorithm. The 
pioneering work by (Malliaris et al., 1997) led to the development of the first injury prediction 
algorithm. Malliaris and his team conducted a multiple logistic regression analysis of data from 
the National Automotive Sampling System/Crashworthiness Data System (USDOT, 1998). For 
several decades, NASS/CDS has reported on motor vehicle crash injuries, their associated 
severities, the crash conditions which produced them (as determined by crash investigators), and 
other occupant and vehicle information. This was done for a sample of all crashes occurring in 
the U.S. each year. Using the NASS/CDS data, the most influential variables for crash injury 
assessment were identified and quantified (e.g., estimated crash delta velocity, principal direction 
of force (PDOF), occupant age, seat belt use, multiple impacts, etc.). This assessment led to the 
creation of an injury prediction algorithm called URGENCY which used the Abbreviated Injury 


4 Note The data used to predict injury, such as crash delta V, direction of impact, etc., is only acquired by AACN 
systems (not ACN (including aftermarket FMV) or SOS). 
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Scale (AIS) as a measure of injury (Champion et al., 1999; (Augenstein et al., 2001). Expecting 
data from crash telemetry and other sources (e.g., conversations with vehicle occupants), the 
URGENCY algorithm was configured to estimate the probability that the ‘maximum AIS’ 
(MAIS) was > 3 (indicating serious injury). MAIS is the highest AIS code sustained by one 
person on any part of the body.” 


Recently, OnStar and University of Michigan researchers developed a multivariate logistic 
regression model, based on the NASS-CDS data (1999-2008) to predict the probability that a 
crash-involved vehicle will contain one or more occupants with serious or incapacitating injuries 
(Kononen et al., 2011). In this model, an Injury Severity Score (ISS) > 15 is defined as a serious 
injury.°° Following the recommendations of the CDC-led National Technical Panel on Field 
Triage, the parameters used in the OnStar/UMI crash injury prediction are crash delta velocity, 
crash direction (front left, right, rear), multiple vs. single impacts, seat belt use (which is detected 
by vehicle sensors), presence of an occupant > 55 years old, presence of at least one female in 
the vehicle, and vehicle type (car, pickup truck, van, sport utility). Some of this information is 
available from the AACN unit, some from voice contact with the occupants (e.g., age, gender). 
The algorithm is applicable to planar crashes only (no rollovers) and all vehicles makes and 
models (not just GM). Although the model predicts a continuous value of probability of injury 
(as does URGENCY), in practice, a cut point is used to differentiate vehicles that meet the 
‘serious injury’ criteria from vehicles that do not. This limiting of the injury severity prediction 
(ISP) output to two states is an attempt to provide a clear, actionable result for operational use. 
The cut point recommended by the CDC Technical Panel (based roughly on clinical experience) 
is 0.2 or 20% probability that a vehicle has an occupant with an ISS score > 15 and therefore 
requires triage to a trauma center. This cut point may well change after additional validation 
efforts are completed. 


The OnStar ISP is now provided to the PSAP call taker by the OnStar advisor and would 
therefore be captured in any approach that went through the PSAP. 


3.2 Methods 


There were four major activities in Task 2. These included 1) characterizing candidate pathways 
for providing OnStar crash telemetry data to the 9-1-1 PSAP and emergency response agencies 
in real time and selecting one of these pathways for a demonstration, 2) developing a web-based 
AACN database framework to enable archiving and post-event access to AACN data, 3) 
simulating a live OnStar call into a PSAP test site to demonstrate the capture and real time 
sharing of AACN data with EMS and hospital medical providers, and 4) establishing a process 
for the capture, use and archive of OnStar AACN data going forward. 


3.2.1. Characterizing Pathways for AACN Information in Montana 


Building on the background presented in Chapter 2, candidate pathways for bringing AACN data 
into Montana and making it available to emergency responders for both operational and research 
use were reviewed. Operational use (as used here), means crash telemetry data is made available 
to 911 call takers, dispatchers, responders, and receiving hospitals to support real-time dispatch, 


°° See http://www.aaam .org/ais/. 
°° The Injury Severity Score (ISS) is the sum of the squares of the AIS level of the three most significant coded 
occupant injuries. The AIS (Abbreviated Injury Scale) runs from 1 to 6, with 1 Minor, 2 Moderate, 3 Serious, 4 
Severe, 5 Critical, 6 Unsurvivable. 
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field triage and hospital treatment decisions. Research use implies acquisition, storage, and 
linkage of crash telemetry data for non-real-time analysis. The intent was to identify options, 
which maximize the utility of the crash telemetry data which is now available, while planning for 
a future where the amount of AACN data available digitally will grow, algorithms to process the 
data will be fully validated, and national protocols to use the data will be firmly established. 


There are three basic pathways for getting AACN information into Montana. There is the 
Traditional route (via a phone call on an administrative line to the PSAP), the ‘Priority Access’ 
route (where selected AACN data goes directly into the PSAP 911 trunk line) and the ‘Condition 
Acquisition and Reporting Systems (CARS)’ route, where AACN data goes to a state server 
usually operated by the state Department of Transportation. The three approaches are discussed 
briefly below. 


Traditional - General Motor’s OnStar was the first commercial ACN system in the U.S. and 
originated the traditional route for communicating a crash alert to a PSAP. Typically, a crash is 
detected by sensors supporting the vehicle’s airbag deployment systems. An emergency message 
is automatically sent using a vehicle-based cellular phone call to the OnStar (TSP) Call Center. 
Besides the Global Positioning System (GPS) crash location (latitude and longitude), other data 
included in the digital message to the TSP are crash delta velocity, principal direction of force 
(PDOF), whether a rollover occurred (for some vehicle models), whether there were multiple 
impacts, and other crash and vehicle-related details. Upon receipt of the automated telematics 
call, OnStar call takers attempt to establish voice contact with the vehicle. If occupants confirm 
that injuries are present and assistance is needed (or if occupants do not respond), OnStar 
contacts the appropriate Public Safety Answering Point (PSAP) by calling a designated number 
for that PSAP. This call from OnStar traditionally came into the PSAP on an administrative 
phone line, NOT on an emergency or 911 trunk line. The implication here is if this 
administrative phone line is in use, the OnStar call may not get through in a timely manner. Once 
the voice connection between OnStar and the PSAP is made, if desired by the PSAP, OnStar 
establishes a conference call between the PSAP, OnStar and the crashed vehicle. 


Priority Access - Priority Access is a mechanism developed by Intrado, a provider of 911 
technology solutions for traditional phone companies, wireless carriers, satellite and cable 
operators, Voice-over-Internet Protocol (VOIP) service providers, and public safety and 
government agencies. Intrado has been working with the telematics service providers to route 
emergency calls from a TSP call center into the 911 trunk system at the appropriate PSAP 
(OnStar, 2007). The call would then come into the PSAP as an emergency call. The major TSPs 
(OnStar, ATX, and Hughes Telematics) are all participating in this effort. 


Priority Access is being implemented in stages. Stage 1 routes the voice call from the TSP 
advisor (who still dials the designated 800# for the PSAP) into the 911 emergency trunk line 
rather than into an administrative line. Thus, an OnStar call is delivered directly to the 911 call 
taker screen along with the OnStar advisor’s call-back number and a visual display of 
“Telematics call” and “OnStar Call Center” indicators. The OnStar advisor then provides verbal 
details on the crash to the PSAP call taker. Requirements for this routing to be implemented are 
1) the PSAP must have Voice-Over-Internet-Protocol (VOIP) capability and 2) Wireless 
Enhanced 911 must be established (OnStar, 2009). Stage 1 Priority Access has now been 
implemented in 46 of 57 PSAPS in Montana, including Missoula (Intrado, 2010a). 
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As originally defined, Stage 2 Priority Access includes the capabilities of Stage 1 OnStar voice 
call into 9-1-1 trunk line, along with electronic delivery of the X,Y coordinates of the crash 
(OnStar, 2007). However, Stage 2 may be expanded to include digital delivery of additional 
AACN fields’’. Achieving Stage 2 has been a very slow process and is currently only operational 
(i.e., providing digital crash coordinates only) in a few locations”® (Intrado, 2010b). With regard 
to the ultimate goal of electronic delivery of the full AACN dataset, Intrado is currently working 
with OnStar and ATX on AACN message content (data fields to be delivered), and on an 
architecture and procedures for enabling delivery of the AACN digital data to the PSAPs”. An 
interface will be needed at the PSAP to bring the data to the desktop and display the AACN data 
fields, which will be automatically populated when fully implemented). At this time, it is not 
clear when delivery of the full AACN dataset will be operational. It should be noted that 
displaying new AACN data fields at the PSAP will require changes to the 9-1-1 call taker’s 
screen and local stakeholder approvals must be obtained. 


Condition Acquisition and Reporting System (CARS) - CARS is an Intelligent Transportation 
System (ITS), standards-based, condition reporting system that allows authorized users (typically 
transportation departments) of participating member state agencies to enter, view, and 
disseminate critical road, travel, weather, and traffic information (CARS, 2010). CARS users 
access the system using a standard web browser (i.e., no local software is required) to enter 
condition reports or view reports entered around the state. As of 2012, seventeen transportation 
agencies have deployed or are currently in the process of deploying the CARS system. CARS 
users include Alaska, the City of Calgary, Idaho, Indiana, Iowa, Kentucky, Louisiana, Maine, 
Minnesota, New Hampshire, New York, the New York State Thruway Authority, Rhode Island, 
Sacramento,, Vermont, and Washington State. Montana, however, is not a CARS member state. 


OnStar recognized the CARS system might be a way to get OnStar data to a number of states. 
They entered into an agreement with the operator of CARS (Castle Rock) to provide the CARS 
system with OnStar messages received from crashes in CARS participating states. OnStar 
implemented software in their message center to automatically sort and transmit crash data to the 
CARS national server located in Atlanta, Georgia. The participating CARS states that want to 
receive the crash message data can then request that the crash data be sent to them. Typically, 
state systems will use CARS to identify and map crash locations as part of their incident traffic 
management systems. However, it is important to note, the provision of AACN data to the CARS 
system is considered to be completely separate from the primary mechanism for alerting the 9-1- 
1 system through the TSP (OnStar) voice call to the appropriate PSAP. 


There have been several projects undertaken which use CARS to provide emergency medical 
service (EMS) responders with access to OnStar data for use in real time operational response. 
Three such projects are Minnesota May Day 911, the Alabama ACN Project and, most recently, 
the Idaho ACN Project (MnDOT, 2005; Funke et al., 2005; Virshbo, 2010). 


The first two were research programs with field tests that have now concluded; the effort in 
Idaho (which has a centralized statewide EMS dispatch center and is co-located with the 
transportation management center (TMC)) has been implemented as a permanent operational 
system. It should be noted those who receive AACN data through CARS, would have the option 


*7 David Sehnert (Intrado), private communication with authors, June 2011. 
*® Cathy Bishop (OnStar), private communication with authors, January 2012. 
*’ David Sehnert (Intrado), private communication with authors, June 2011. 
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of using the URGENCY algorithm to calculate an injury severity. This is, in fact, done in Idaho. 
However, seat belt use is not included in the AACN data provided to CARS by OnStar (for 
privacy reasons) and so this parameter cannot be used in the URGENCY calculation unless it is 
acquired after responders arrive at the scene. 


3.2.2 Options for Getting AACN Data to Responders 


Using the pathways described above, the research team developed a set of options (with 
tradeoffs) for getting AACN information into the hands of responders. Table lon the following 
page lists Options 1 through 4. The column headings across the top of the table follow the flow 
of crash-related data as the response to the crash event unfolds. It starts with the initial PSAP 
crash notification and steps through PSAP receipt of the traditional ‘primary’ crash information 
(such as crash location, witness information, etc.). This is followed by PSAP receipt of AACN 
data and receipt of AACN data by agency dispatchers (for first responders, police and EMS), as 
well as receiving hospitals. This latter group is referred to as ‘stakeholders’ in the table. The next 
to last column addresses how the AACN data can be incorporated into a research database (to 
support performance and effectiveness studies). The final column provides comments regarding 
what the option requires or produces. Reference numbers in brackets point to footnotes at the 
bottom of the table. The light shading of a cell in the table indicates no action by the team is 
necessary to accomplish the task. Darker shading of a cell indicates the task requires actions to 
be performed by the team as part of current effort. 


The PSAP was assumed to have a Priority Access Stage | capability as a starting point. As 
indicated previously, many of the PSAPs in Montana, including Missoula, are at Stage 1. Thus 
for Options 1 through 4, the initial crash notification from the TSP comes into the PSAP over the 
911 trunk line, and is labeled as an emergency ‘Telematics Call’ (or Stage 1 Priority Access). As 
indicated by the lighter shading, no action is required by the team for this step (all options). 


The survey conducted as part of Task 1, noted the use of ‘CAD Status’ software at some PSAPs 
(e.g., Missoula). CAD Status allows any agency dispatched by the PSAP to view emergency 
calls on the PSAP screen live (via internet), as the incident is unfolding (Golbeck, 2010). The 
notation “share image of PSAP screen with stakeholders” shown for the Priority Access Stage 
1B option, assumes the availability of this type of software. 
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Table 1. Options for Transmitting AACN Telemetry Data 
Step-wise Flow of Crash Related Data 


EMS, Public 
Safety 1° 
: ; : Responder Research 
PSAP Crash PSAP Receipt of | PSAP Receipt of Dispatchers, & Dihaw 
Options Notification Primary! Crash Detailed AACN Récetving Acruast on ee Comments 
/Alert Information Data Hospital AACN Data 
Receipt of 
AACN Data 
: oe Verbal -No changes to PSAP 
Sake Traditional verbal Zeon vaval transmission of | Acquire hand- CAD System required. 
a z ; DEN information [1] hae AACN data written PSAP -AACN data provided 
1.Priority Pines from TSP provided Mucins) from PSAP AACN record verbally to 
Access appears as to PSAP over 911 lonucitien GA call taker to (post event), and | stakeholders in real 
Stage 1A Emerency trunk (not Admin paper forms by stakeholders enter data into time. 
line). Recorded per for real time research -Electronic AACN 
pica normal rotocol ESE eal ake: operational database Research Database 
Call’ Pp 14] p 
use. (DB) created. 
-Share image 
Additional verbal eee th -May require changes 
AACN data from | S7° Transfer data (in | to PSAP CAD screen 
: stakeholders : 
TSP Voice THonalebal TSP (AV, crash since screen images) (unless only Comment 
Call to PSAP enon direction, etc.) service) [SIIOR to research field used)[5]. 
2.Priority | ito 911 from TSP to PSAP_ | Sulered into -Extract doubose Oe 
A . y trunk line Te dedios ono CAD/computer elostoniedata -Export AACN -Creation of web site 
S ‘i i B appears as i a ae by PSAP call AGG aah data elements provides AACN data 
Be emergency Recorded d ee taker [4]. Entries PSAP CAD from web site visually (or digitally) 
“Telematics a eeaaee : 1 made into Hapacae server to to stakeholders 
Call’ > oe predefined data . i ne b research 
fields or - es . ie database Electronic AACN 
comment field. oe ee Research DB created. 
stakeholders. 
ee -Changes to PSAP 
of PSAP : 
screen wath CAD screen required. 
Selected AACN Remaining eenolde Transfer data (in | -Some AACN data 
3. Priori TSP Voice data transmitted verbal AACN an sa screen images) (location, other?) 
ry monty Call to PSAP | electronically over | data from TSP ice) [SIIOR to research provided digitally to 
: see into 911 911 trunk line to (ISP, AV, crash eta ; database [7],OR | PSAP reducing data 
No trunk line PSAP screen: direction, etc.) ieee data -Export AACN entry required. 
Cureen appears as Latitude/ entered into eee data elements -Creation of web site 
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Traditional verbal =P eno eee 
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4.CARS + PSAP into from OnStar to Extract data -Data entry by PSAP 
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g as Pee web browser. web browser record available to 
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emergency stakeholders in real 
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display screens [3] 


Research DB created. 


= 
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Does not require any action by research team 


Requires tasks to be performed by the team as part of current effort 


32 


Notes for Table 1. 

[1] ‘Primary’ Crash data refers to the data currently available to PSAP call takers (e.g., crash location, etc.) 

[2] Originally, Stage 2 was only to digitally deliver X,Y coordinates of crash. It is not known at this time (Jul 8, 2011) whether 
additional AACN data elements may be included in the Priority Access electronic message; details of crash message content are 
currently under review by Intrado, the TSPs (OnStar/ATX), and other interested parties. 

[3] Once OnStar initiates call to PSAP, OnStar advisors forwards AACN data to CARS (if crash is in a CARS state). The key to 
the use of the CARS option is to provide stakeholders access to the website displaying the AACN data. 

[4] This step will require cooperation of the OnStar advisor to provide AACN data and willingness of PSAP call taker to request 
and record it. Expect data will be entered into PSAP CAD system, but may be separate. 

[5] AACN data entered as ‘prescribed free text’ in the ‘Comment’ field on the CAD screen would enable consistent (post-event) 
extraction of AACN data from comment field using an automated software script (e.g., verbal statement from TSP that “crash 
delta velocity was 38 mph and OnStar injury severity prediction is 32%” could be entered ‘DV=38mph’, ‘ISP=32%’. Actual 
number of keystrokes may even be fewer than typically used now by call taker. 

[6] Given that selection and format of AACN data element fields for inclusion in Stage 2, 3 electronic message are still under 
review, AACN defined fields created on PSAP screen in this option will likely need to be changed when Stage 2, 3 fully 
implemented. This approach may, therefore, be a little premature. 

[7] Sharing (viewing) PSAP screen can be done live using CAD Status if this software is installed at PSAP. Otherwise, image of 
screen (with updates) can be transmitted to a stakeholder (password-protected) website where it can be preserved after the event. 


3.2.3. Evaluation of Pathways and Definition of Approach for Montana 


CARS provided a valuable route for making detailed AACN data from OnStar available to 
research projects in Minnesota and Alabama. These projects demonstrated the value of AACN 
data for emergency response. CARS has also proven to be a viable operational route for getting 
detailed AACN data to the EMS responders in Idaho where the EMS dispatch process for the 
state is centralized. However, given the distributed nature of emergency dispatch and decision- 
making in Montana, the CARS route does not appear easy (and may not be cost-effective) to 
implement and maintain, given that Montana is not using CARS for any other incident or 
highway management support (unlike Idaho). With CARS resident on a state server with no 
linkage to the 9-1-1 system, concerns related to how responding agencies will be alerted that data 
is available and will responding agencies have the time or opportunity to access a website to 
view data in the middle of a response, are issues which must be considered. On the plus side, 
some AACN display, archive, and injury prediction software (i.e., URGENCY) would be 
available from Idaho which would reduce some implementation costs. However, CARS is 
limited to receiving OnStar data only (no ATX or Hughes data), and there are no guarantees of 
future support by OnStar. CARS also does not, at this time, receive the OnStar ISP. If the 
URGENCY algorithm is used in place of ISP, seat belt use is not included because of privacy 
reasons, in the AACN data provided to CARS and cannot be used in the URGENCY calculation 
unless seat belt use is acquired from a conversation with vehicle occupants. 


Priority Access is an attractive route because it gets the initial crash alert into the 9-1-1 
emergency system and when Stage 2 and 3 are fully implemented, will forward AACN 
electronic data to the local PSAP CAD system rather than to a computer at a state or municipal 
agency. Priority Access is also moving along a pathway which will merge/be consistent with 
Next Generation 9-1-1 and is therefore a solution for the future. It furthermore provides a route 
which accommodates all AACN systems and telematics service providers (OnStar, ATX, and 
Hughes Telematics) as well as all operational models (e.g., TSP vs. Ford Syne model). Finally, 
Priority Access, when fully implemented, is expected to electronically deliver the Injury Severity 
Prediction (ISP), which uses seat belt status as input to the ISP algorithm. 
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The benefits and drawbacks of the two primary (non-traditional) pathways, namely Priority 
Access and the CARS system, are summarized in Table 2. 


Table 2. Benefits and Drawbacks of Pathways 


Priority Access CARS 
(to 9-1-1 PSAP) (to a State Server) 
Benefits Drawbacks Benefits Drawbacks 
* Will provide access to We Pksee te a ith 
OnStar ISP algorithm ¢ Currently provides en ieee scene eee: 
* Expected to provide *Would require PSAP | detailed digital crash = a Se ee & 
access to other AACN to record verbal data | data. Sai eae : a 
systems (besides OnStar) from TSP into digital | * Some display, na yee - 7 
* No recurring costs record until Stage 2 is | archive & ISP aia . ak : OnSt 
¢ Pathway to future NG911 | operational. algorithm software Ay is — : : . 
* PSAP may share record may be available from ; ake a uae i 
with local EMS Idaho po aap ee y DNStii 
* Not expected to receive the 

eee OnStar ISP data. 


In May 2011, the Research project technical panel selected Priority Access using CAD Status. 
As this option was pursued, it became apparent (during discussion with PSAP staff) that any 
changes made to the PSAP screen (i.e., the addition of new data fields) would be a lengthy 
process because of the approvals needed to modify an operational 9-1-1 screen. Although this 
modification will have to be done when the full AACN data set is ready for delivery 
electronically, it seemed premature to do so now when requirements and standards for this 
delivery were not yet fully defined. However, an opportunity to develop an interim (and simple) 
solution for electronically capturing AACN data presented itself. If verbally-recetved AACN 
information (such as crash delta velocity, ISP, etc.) is entered in a prescribed manner into the 
‘Comment’ field on the PSAP screen, this data could be shared with emergency responders in 
near real time via CAD Status and consistently documented electronically in the PSAP call 
record, without significantly adding to the PSAP call-taker’s work load. Post-event, the AACN 
data could be extracted from the ‘Comment’ field using (as suggested by PSAP staff), an 
automated software script which searches for the ‘prescribed text’ and exports it with rest of 
crash record to a file for inclusion in the AACN research database. This crash record could also 
be made available for incorporation into the patient medical record to document mechanism of 
injury. This hybrid (part manual, part automated) approach for recording verbally-provided 
AACN data provides a relatively simple mechanism to collect the data of interest when relatively 
few crash events are experienced (as is the case, at present, in Montana). This approach could 
also be implemented in PSAPs with varied types of computer or CAD systems. 


Once State 2/33 Priority Access is available and local approvals to change PSAP screen are 
obtained, AACN data will automatically populate designated fields on the PSAP screen. When 
this occurs, PSAP call takers and emergency responders will already be quite familiar with the 
data and its use. 


3.2.4 Selection of PSAP Test Site for Demonstration 


Criteria for PSAP selection included: 1) interest and willingness of the site (and its response 
agencies) to participate in the project, 2) site should be located in a geographic area that 
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experiences a relatively large number of crash events and 3) site should be located in an area that 
has a trauma center. 


Data on the total number of fatal and injury crashes for the candidate locations were compiled 

from various Montana state sources. Cities with trauma centers in Montana were then identified. 
Table 3 provides a tabulation of this information. The shaded areas indicate maximum values in 
each column. 


Table 3 Data to Support Site Selection 


City with County Trauma Fatal Serious Total Non- County Other 
Trauma Center Crashes Injury Fatal Injury | Population Considerations 
Center (TC) (K)* Crashes* Crashes (7/1/2009) 
Levels | (2008-2009) | (K+A+B) in (A+B+C)* (c) 
(b) in County County (2008-2009) 
(a) (2008-2009) (a) 
(a) 
Missoula Missoula Il, Ul 31 1425 109623 
Billings Yellowstone | II, II 658 -Two TCs (II, ID 
Kalispell Flathead Il 36 583 980 89624 
Great Falls | Cascade II 13 421 1046 82178 
Bozeman Gallatin Il 16 357 776 90343 
Butte Silver Bow | Ill 12 135 291 32949 
Sources: 


a) Crash Data: http://www.mdt.mt.gov/publications/datastats/crashdata.shtml (K=killed, A=incapacitating injury, B=non- 
incapacitating injury, C=possible injury, O=no injury.) 
b) Trauma Center Data: http://www. facs.org/trauma/Vverified. html 
c) Population Data: http://ceic.mt.gov/EstimatesCntyPop.asp 


After reviewing the candidate locations, the research team and the project technical panel 
concurred that the demonstration be conducted in Missoula County. Inquiries were made with 
OnStar to estimate the total number of AACN calls that might be expected in Montana. In a 
recent one-year period (June 2010 to end of May 2011) Montana had a little less than 100 actual 
AACN events*’. This number is expected to increase as more vehicles with the advanced 
systems make their way into the fleet. However, this figure can be used now to estimate how 
many AACN crashes might be expected per month in Missoula County. According to 2010 crash 
statistics for Montana, the total number of fatal plus(+) injury crashes for the whole state of 
Montana was 5133 of which 601 (11.7%) occurred in Missoula County (MDT, 2010). The total 
number of fatal plus (+) incapacitating injury crashes for the state was 943 of which 163 (17.2%) 
occurred in Missoula County. Scaling the annual number of AACN crashes in Montana using 
these percentages, it is expected that Missoula County will see somewhere between 11 and 17 of 
the expected 100 AACN crashes in Montana in a year (or between 0.975 and 1.43 crashes per 


month). 


°° Jeff Joyner (OnStar), email message to authors, June 10, 2011. 
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3.2.5 Approach for Archiving AACN Data 


A mechanism is required for archiving the AACN data as it is collected so that it is available in a 
form useful for review by clinicians interested in mechanism of injury, as well as for researchers 
working to validate injury severity prediction algorithms. Stakeholders were engaged in an 
iterative process to design and test a password-protected, web-based data archive. Beta testing of 
the archive was performed using mock data and access was provided to both the stakeholders 
and members of the technical panel. Several modifications to the website and data archive were 
made in response to their feedback. 


The information technology (IT) staff at the Missoula PSAP created an automated software 
script that scans the PSAP database for OnStar calls. This script is automatically run once each 
week and the Excel file it produces is emailed to the organization maintaining the server for the 
MT-AACN database even if no OnStar calls are received, in which case, the contents of the data 
fields are blank. (The database is currently housed at CUBRC but will eventually transition to 
MT DPHHS). This extraction of selected information from the PSAP call record database and 
emailing of summary reports follows standard (approved) PSAP reporting procedures. Figure 7 
on the next page shows the ‘Home’ page for the website. The black navigation bar at the top 
allows the user to access the ‘Home’, ‘About’, ‘Stakeholders’, ‘Background’, and ‘Contact Us’ 
pages without logging into the site. Clicking either ‘Login’ or ‘Data’ will bring up the 
username/password page which enables registered users to view the AACN records. 


: sera 
EOF emargoncy Care 911 


I) OCPARTMENT OF TRANSPORTATION 
Home About Stakeholders Background Contactus 


Crash Telemetry Data 
PDOF= 1 o'clock 
Welcome to the MT AACN Web Portal poe Rett 
Rollover with Airbag Deployed 
This portal enables post-event viewing of Advanced Automatic Crash Notification (AACN) ISP=High 
data obtained from motor vehicles in Montana that are equipped with AACN technology and 
experience a significant crash event. The data from these AACN crash events are entered into 
the MT AACN Database 


Rationale for Development 
CFSid TSP Caller 


This viewing portal was developed specifically for Montana's emergency medical community 
to help them gain familiarity with AACN crash telemetry data and the use of such data in crash [ia Oniter | 
injury prediction algorithms. Understanding the utility of this data is important because x 


e Injury prediction will help support future medical direction, triage and transport decision- ‘OnsSter Ls 4, 2009 $29.32 PM 
making in real ime ” ” 

e AACN data can be linked with pre-hospital and hospital patient care records, providing 
supplemental data for future use in assessing effectiveness of various treatments and 
overall trauma system response 


Database Content and Access 


% Probability 


The database contains OnStar AACN events (current data is fictitious) which occurred in 
Missoula County, Montana. To view AACN data records, Login or Contact Us to request 
access ran 


Figure 7. Home page of the MT AACN database website 
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Figure 8 shows an image of material contained on the ‘About’ page including information on the 
origin of the AACN data which will be housed in the database. 


Web Portal Development 


This portal to view the MT AACN Database was developed as part of the Montana ACN Project led by the University of Montana with 
technical support from CUBRC. Funding for this effort was provided by the Montana Department of Transportation 

¢ The Montana ACN Project also includes a pilot demonstration (in Missoula) of a systern to provide AACN crash-related information to 
emergency medical responders in real time. The Missoula 9-1-1 Public Safety Answering Point (PSAP) is a key partner in this 
demonstration 


Origin of Data in MT AACN Database 


After receiving a crash alert from a vehicle in the Missoula area, the Telematics Service Provider (OnStar) places a call to the Missoula 
9-1-1 PSAP. The PSAP call-taker verbally acquires selected AACN data and a prediction of injury severity from the TSP and documents 
the information (in a structured format) in the ‘Comment’ section on the PSAP screen. The PSAP then shares the information with 
emergency responders and medical personnel in real time, by enabling dispatched agencies to view the PSAP screen ‘live’ over the 
internet, as the event unfolds 

e An automated software script is executed post-event to retrieve the AACN data from the PSAP call record and export it to the MT AACN 
database. Data records can then be accessed and displayed via the web viewing tool provided here 


Crashed Vehicle Telematics Call Center 9-1-1 PSAP Real time viewing of 
___5] AACN data ‘live’ on PSAP 
: screen by responders 
- oF Post-event retrieval of Database accessed 
a a e > AACNdatafrom PSAP call |__| & crash data 
. Dé 


record. Data imported displayed using 
into MT AACN Database. web viewing tool. 


Figure 8. Webpage portal and the origin of AACN data 


Figure 9 shows the page which appears when ‘Data’ or ‘Login’ is clicked on the Home page and 
Username and Password is entered. The table at the top lists all the AACN records currently in 
the database. Note that crash records shown in the figure are simulated test data for illustration 
purposes, not actual AACN events. The column headers in the table can be used to sort the 
records. There is also a Search tool which allows the user to display only those crashes with 
selected criteria (e.g., Multiple Impact = True, or Crash Delta Velocity greater than XX mph, or 
ISP = High, etc.). Note: Current version of OnStar ISP algorithm is valid for ‘planar’ crashes 
only (Kononen et al., 2011). It is possible that ISP will not be provided by OnStar (at this time) if 
Rollover=True. 
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Logout 


Rows per Page: | 10¥) List of Records in Database Search 


CFS No. TSP Case ID TSP Caller Time of Alert ESiaieticy) Field: [Crash Delta Velocity iM 
Operation: 


MC012712-19 | 446388781 Jan 27, 2012 8:22:09 AM | Missoula __| Value: {20 


(Submit) (Clear ) 
mco90411-18 | 311223484 Sep 4, 2011 10:23:29 AM 


Showing results for: 


MC072011-10 168532164 Jul 20,2011 11:40:04 AM_| Missoula _| Crash Delta Velocity greater than 


Use search tool to 
“Test Data NOT actual crash events restrict list to 
crashes with 
selected crash 
characteristics 


Page 1 of 1 TEST DATA — NOT ACTUAL CRASH EVENTS 
Total Rows: 7 


After ‘selecting’ crash recordin table above, 
> AACN Crash Data € click text to display AACN data 


Click text to display Google map of crash location 
> 
Map © for highlighted record. 


Figure 9. List of simulated crashes in database. 


Figure 10 shows how the AACN data for a selected AACN crash record is displayed (again, data 
is from a simulated crash event) and Figure 11, on the following page, shows a Google map of 
the simulated crash location. 


w~ AACN Crash Data 
TEST DATA — NOT ACTUAL CRASH EVENT 


Event & Vehicle Information Crash Characteristics Injury Severity Prediction 
CFS No. MC050312-4 
TSP Case ID 125489017 . 100 20 to 100% 
TSP Caller OnStar 80 Probability 
Vehicle Make Chevrolet r Te nol 
; : = vehicle wi 
— Model Malibu 3 60 ia 
ehicle Year ° Severity 
Time of Alert. May 3, 2012 10:15:10 AM = “0 Score 2 15 
x 
Tee a! May 3, 2012 10:16:23 AM | Direction of impact #1 Right 20 - 
___ 7938 Grant Creek Rd, Pre-Crash Heading 
Crash Location icc oulg Airbag Deployed? True 7 ISP 
Roll Over? True 
Multiple Impacts? False Injury Severity Prediction: High 
Crash Delta Velocity Impact #1 25 mph 


Figure 10. AACN data for crash record ‘selected’ in previous figure. 
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~ Map 


Print Map 


"Locations are approximate 


Figure 11. Google Map showing Crash Location 


3.3 Test Call Demonstration 


3.3.1. Preliminary Organization & Planning 


The CUBRC research staff visited Missoula and met with each of the local stakeholders at their 
facilities to secure their involvement in the organization and execution of an OnStar AACN test 
call demonstration where AACN data is acquired at the PSAP and shared with emergency 
agencies and hospitals. The stakeholders (full list in Appendix A) included Chris Lounsbury 
(PSAP), Don Whalen (Missoula Emergency Services Incorporated), John Bleicher (St. Patrick’s 
Hospital), Traci Jasnicki and John Stred (Community Hospital), and Larry Peterman (LifeFlight). 
During the visits, the researchers presented the proposed test and solicited inputs from the local 
stakeholders on both the content and plan of operations, which resulted in several refinements. 


Following the site visit to Montana, CUBRC staff continued to work with Chris Lounsbury, 
Missoula Emergency Services Director, to plan the Missoula demonstration. They negotiated an 
arrangement to integrate the AACN demonstration into ongoing PSAP protocol and planned for 
recording of the AACN data received verbally from the OnStar Advisor using “prescribed” free 
text in the ‘Comment’ field on the PSAP CAD screen. A live image of the PSAP screen would 
then be shared with stakeholders for real time operational access to the AACN data. This data 
would subsequently be extracted from electronic PSAP records and archived in the MT AACN 
Database for later use in analysis and research. In response to stakeholder requests, the research 
staff also developed a tutorial on injury severity prediction (Blatt, 2011) and another on the 
concept of operations for the collection and use of OnStar-provided Injury Severity Prediction 
(ISP) (Blatt and Flanigan, 2012). The intent was to use these tutorials to help orient emergency 
response staff prior to the demonstration. 
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A script was prepared for the AACN test call, which described the simulated crash event. Table 4 
(Section 2) summarizes the simulated AACN data which was to be requested by the PSAP call 
taker during his/her conversation with the OnStar Advisor. Also shown in the figure is other 
simulated test data routinely ‘acquired’ by the call taker (Section 1) and by EMS at the scene 
(Section 3). 


The script also contained specific instructions for each of the participants at the various sites. It 
basically provided a demonstration time line and actions that would be taken by each participant. 
A copy of the full script is contained in Appendix C. 
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Table 4. AACN test call data provided in script to particpants 


1. Standard Data - Currently received or acquired by PSAP Call Taker from OnStar Caller 


Item Sample input Notes 

Caller Name OnStar TEST CAD data field automatically populated (Priority Access Phase 1) 
Call Back Number 800-xxx-yyyy CAD data field automatically populated (Priority Access Phase 1) 
Vehicle Make Chevrolet Verbally acquired; entered into CAD / Comment Field 

Vehicle Model Malibu Verbally acquired; entered into CAD / Comment Field 

OnStar Case Number | 125489017 Verbally acquired; entered into Comment Field 

PSAP Call Date mo/day/year CAD data field automatically populated 

PSAP Call Time hr:min CAD data field automatically populated 


Incident Street 


7938 Grant Creek Rd 


Verbally acquired; entered into CAD 


Incident City 


Missoula 


Verbally acquired; entered into CAD 


Number Injured 


2 Verbally acquired (if TSP contact with vehicle occupants); entered in CAD 


2. Additional AACN Parameters - Verbally requested from OnStar and entered in PSAP ‘Comment Field’ using 


Item 


Injury Severity Prediction 


Multiple Impacts? 


Crash Delta Velocity (mph) 


Direction of Impact 


Rollover? 


Time of Alert 


pre-defined notation (Q" column) below: 
Sample input Notes 
ISP HIGH 
MIMP No 
DV1 25 


DIR IMP1 


from Right 
Rollover Yes See Note** 


(hrs:min) 


Reported (by OnStar) as HIGH or LOW (but computed as percentage). 


Units are miles/hour. (Can be a DV2 if Multiple Impacts (i.e. if MIMP Yes) 


Choices are Front, Right, Left or Rear. (Can be a DIR IMP2 if MIMP=Y; 
Here only first (or max) impact delta V and direction recorded) 


Time alert received at TSP (OnStar). 


3. Other Test Data ‘Acquired’ by EMS (simulated at scene) 


Item 


Sample Input 


Notes 


Patient | 


Patient 2: 


-Unbelted male, 45 yrs old, ejected 

-Injuries / vitals (defined by EMS); 

-Transport by air (LifeFlight) to St Patrick’s Hospital 
-Chevrolet Malibu 

-Belted male, 50 yrs old; 

-Injuries / vitals (defined by EMS) 

-Transported by ground (MESI) to Community Medical 
-Chevrolet Malibu 


Passenger, OnStar Vehicle 


Driver, OnStar vehicle 


Patient 3: 


-Belted female, 65 yrs old; 

-Injuries / vitals (defined by EMS); 

-Transported by ground (MESI) to St Patrick Hospital. 
-Ford Focus 


Driver, Non-OnStar vehicle. 
TRANSPORT NOT SIMULATED IN 
TEST CALL 


4] 


3.3.2 AACN Message Routing Demonstration 


The Advanced Automatic Crash Notification (AACN) message routing demonstration was 
conducted in Missoula, MT on May 3, 2012. The demonstration was conducted to illustrate how 
crash telemetry data from a motor vehicle equipped with OnStar could be effectively captured 
for use by emergency responders and medical providers in real time, as well as archived for later 
use by clinicians and researchers. The demonstration took place at five Missoula locations, 
namely: Missoula 9-1-1 Public Safety Answering Point (PSAP), Missoula Emergency Services, 
Inc. (MESI) Ground Ambulance Depot, Community Medical Center, Life Flight Air Medical 
Base, and St. Patrick’s Hospital. Missoula City Police observed the call at the 9-1-1 PSAP. 
Participants at the PSAP included Chris Lounsbury (Missoula County Emergency Services 
Director), the 9-1-1 call taker on duty, and Drew Koepke (PSAP Technology Coordinator). 
Figure 12 and Figure 13 summarize the key activities performed at each of the sites. 
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AACN Test Call Data Routing Demonstration 
Missoula, MT 


Missoula PSAP (Observed 
by Tom Seekins (UMT)) 


Missoula PSAP 
Receive call from Missoula Police 
Announcement OnStar, record initial View Test Call 
Simulate OnStar of TEST CALL info in CAD, dispatch via CAD Status 
Call to PSAP emergency services, Fire Units 
collect additional data View Test Call 


via CAD Status 


Dispatch request 
received at Life 
Flight Comm Ctr 
Dispatch request (Spokane) and 
(via pager) dispatch message 
received at MESI sent to Missoula 
by Ground 
Ambulance Crew 
| 


Dispatch request 
(via pager) 
received at Life 
Flight Missoula. 


OnStar data 
viewed via CAD 
Status on 


OnStar data 
viewed via CAD 


Simulated en route Status on 
patient & vehicle* LifeFlight Base 
info transmitted via 


Computer 
phone to hospital 


(Community 
Medical Ctr) 


Simulated en 
route patient & 
vehicle* info 
transmitted via 


phone to 
Charge nurse St Patricks 
records patient & 
vehicle info from en 
route call. **Views 
OnStar data via hints a 
CAD Status in ER records patie! 


info from en 
route call 


Arriving patient 
record started. 
En route EMS 
report with patient 
vehicle included. 


Arriving patient 


* For test call, make/model of patient vehicle acquired from script. 
** Health Unit Coordinator monitors CAD Status in ER 


Figure 12. Activities at AACN Data Routing Demonstration Sites in Missoula 


43 


~< EMS > << Trauma Centers——_—» 
Community St. Patrick 
MESI Comm MESI Medic Med Center Hospital 
: - Charge Nurse Charge Nurse 
Simulate Receive 
OnStar Call to standard 
Missoula ‘OnStar’, info, 
PSAP Enter into CAD 
Call Lifeflight Receive Reais 
ar Monitor CAD Simulated Simulated 
and MESI ‘ R tf 
, Status Dispatch quest for 
dispatch Message Services. 
oP: Monitor CAD cet 
Query ‘OnStar’ Review info via Status eaeine on 
for add'l AACN CAD Status (on CAD Status 
info. Enter into Toughbook), A 
Comment field Note OnStar pee! 
crash & vehicle Vehicle Info. 
info 
Associate 
Associate simulated 
simulated victim with 
victim (driver) OnStar vehicle 
with OnStar and ISP ; : 
Vehicle & ISP a Pa’ Receive call Receive call 
Hosp with an from MESI from LifeFlight 
Call Community route patient Medic. Note Medic. Note 
A A ; Patient from Patient from 
Med Ctr with en info. Identify as A Fi 
A : OnStar vehicle OnStar vehicle 
basa cab OnStar patient, & note ISP & note ISP 
info. Identify as vehicle model, = 
OnStar patient, IsP Record Patient Record Patient 
vehicle model, Vehicle Model Vehicle Model 
ISP Document in Patient in Patient 
x patient vehicle Ambulance Hosp.Trauma 
Document in pre-hospital Call Record Record 
patient vehicle report. nclude copy of (Include copy of] 
in pre-hospital CAD Status CAD Status 
report. Screen in Screen in 
Patient Record Patient Record 
Execute Script 
to extract CAD 
info and email Access and Access and Access and Access and Access and Access and 
to CUBRC Review OnStar Review OnStar Review OnStar Review OnStar Review OnStar Review OnStar 
— Crash Crash Crash Crash Crash Crash 
Database Database Database Database Database Database 


Figure 13. Actvities at AACN data routing sites as they evolved 


3.4 Results and Findings 


3.4.1 


Linkage of AACN Data to Vehicle Occupant 


One of the key findings of the test call actually became apparent during the planning for the 
demonstration. In a multi-vehicle crash, the AACN crash telemetry data and the resulting ISP 


only applies to the occupants of the OnStar AACN-equipped vehicle. What was not appreciated 
previously was that once the occupants were removed from the vehicles, traceability of occupant 
to vehicle could be lost unless someone at the scene makes note of which crash victim came out 
of the AACN-equipped vehicle. Furthermore, if both vehicles in a crash are AACN-equipped, 
there will be two ISP values. It will therefore be necessary to note the actual make and model of 
each vehicle and document which patient came out of which vehicle so that the correct ISP is 
applied to the correct patient. As a result, one of the requirements placed on the EMS responders 
participating in the test call, was that they must learn the make/model of the vehicle their patient 
was in and communicate it to the charge nurse at the hospital, either during the en route patient 
report or when the ambulance (or helicopter) arrives at the hospital. For the purposes of the 
demonstration, the make/model of each vehicle was provided in the script. However, the 
requirement to determine make/model of the patient vehicle at an actual emergency scene cannot 
be placed solely (if at all) on the EMS provider since care of the injured patient comes first. 
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Alternatively, if all first responders, police, and EMS who respond to a scene are made aware of 
the importance of this information, someone is likely to have the time to verify and communicate 
this information verbally to the paramedic. Protocols for how this might be accomplished most 
effectively should be left to the local response agencies. 


Make and model of the OnStar vehicle is one of the required parameters, which the PSAP will 
obtain from the OnStar Advisor, should this information not be otherwise volunteered. 


3.4.2 Test Call Demonstration Results 


Activity at the PSAP - Activities at the PSAP are shown in box ‘1’ in Figure 12. At 10:22 MDT, 
Chris Lounsbury, acting as the OnStar Advisor, placed the simulated call from OnStar to the 
Missoula 9-1-1 PSAP. Figure 14 contains the Computer Aided Dispatch (CAD) Call for Service 
(CFS) record. This figure shows (at top right) that at 10:22:35 the call from OnStar was received. 
At 10:22:41, the PSAP call taker began the call record with the notation “TEST CALL.’ She then 
entered the initial information on the simulated OnStar crash. This information indicated two 
vehicles were involved, the crash occurred at 7938 Grant Creek Road,*’ and two people were 
known injured.” At this point, the call taker announced to the room that they had an injury 
crash. A dispatcher (in the same room) acknowledged the call taker’s statement and immediately 
began the dispatch process, while the call taker continued to enter information acquired from the 
OnStar advisor. This information included the following facts: 

e That the OnStar vehicle was a Chevy Malibu 

e The second vehicle type was unknown 

e The case number assigned by OnStar was 125489017*° 

e The Injury Severity Prediction (ISP) was HIGH, there were no multiple impacts 
(MIMP No), the delta velocity (DV1) experienced in the crash was 25 mph 
The direction of impact (DIR IMP1) was from the right and a rollover occurred 
e The ‘time of alert’ (when OnStar first received the crash message) was provided 


3! Note: Since the call was placed by Chris Lounsbury from the PSAP building, the incident address had to be ‘changed’ from the 
(auto-populated) PSAP address to the incident address on Grant Creek Rd. This is reflected in the entry at 10:22:54. 

*? Number of people injured would come from the OnStar Advisor talking with occupants in the car, NOT from crash telemetry. 
33 The OnStar Case number is important should re-connection with OnStar be necessary, or if post-event follow up is needed. 
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CFS REPORT 
ZONES: MESI AMBULANCE, CF35 CITY FIRE STATION 4, CORONER, CITY POLICE ZONE i 


NORTH 

CPS NUMBER: MC050312-116 DATE/TIME REC'D: 05/03/12 10:22:35 
CASE NUMEER: DATE/TIME SENT: 05/03/12 10:23:49 
INC CODE: 302 DESC: VEHICLE-Personal DATE/TIME CMPL: 

INC ADDR: 7938 GRANT CREEK RD APT#: CITY: MISSO PH#: (800) 888-1234 
COMP NAME: onstar COMP ADDR: PH# : 

IN PROG: OFF CONT: PRI: 1 WEAPON: ALARM: PRI UNIT: C10 
CALLTAKER: PHONES :110 DISPATCHER: FMA:s9 

PINAL DISP: 


UNITS ATTACHED: #C10 141 111 110 CF4 #MED1 LF 


COMMENTS: Pager 05/03/12 10:25:55 Successfully paged: CITY _FIRE 
PHONES:110 05/03/12 10:24:36 OP CHRIS 

PHONES:110 05/03/12 10:24:18 TIME ALERT 1023 

PHONES :110 05/03/12 10:24:12 ROLLOVER YES 

PHONRS:110 05/03/12 10:24:07 DIR IMP1 PROM THE RIGHT 
PHONES:110 05/03/12 10:23:58 DV1l 25 MPH Advancing 
Pager 05/03/12 10:24:41 Successfully paged: MESI ‘ 

PHONES:110 05/03/12 10:23:44 MIMP NO Time 

PHONES:110 05/03/12 10:23:38 ISP HIGH 

PHONES:110 05/03/12 10:23:30 CASE 125489017 

PHONES :110 05/03/12 10:23:19 UNKN 2ND VEH 

PHONES:110 05/03/12 10:23:11 CHEVY MALIBU 

PHONES :110 05/03/12 10:23:05 2 PPL INJURED UNKN FURTHER 

PHONES:110 05/03/12 10:22:54 Inc Address changed to 7938 GRANT CREEK RD at 10:23 


PHONES:110 05/03/12 10:22:47 2 VBHS 
PHONES:110 05/03/12 10:22:41 TEST CALL <~————————_ Start “TEST CALL’ 


VEHICLES: 

PERSONS: 

RUNTIMES ASSOCIATED WITH CALL: 

UNIT SUBUNIT STATUS TIME 

110 DISP 10:25:02 
111 DISP 10:25:02 Advancing 
141 DISP 10:25:02 ; 

c10 DISP 10:25:02 Time 
cF4 DISP 10:25:02 

LF DISP 10:25:07 

MED1 DISP 10:25:02 


Figure 14. Call for service (CFS) report from PSAP CAD screen 


While the call taker was acquiring and entering this information, the dispatcher had already 
begun paging emergency services via radio/phone. This voice page began with “This is a test, 
this is a test, do not respond.” She then conveyed information about the crash event as presented 
on the CAD screen, repeating ‘This is a test, do not respond’ midway through the incident 
description. The dispatcher sent (voice and text) pager messages for the ‘simulated dispatch’ 
request to MESI (MED-1 ground ambulance), first responders from City Fire (Units 141, 111, 
110, CF4), Life Flight (LF) (both directly and through the Spokane air medical communication 
center) and Missoula City Police (Unit C10). The ‘Unit’ numbers for these responding agencies 
are listed at the bottom of the PSAP CAD screen shown in Figure 14. (Note: Agency names 
associated with the unit numbers are provided in a figure presented in the next section.) 


All dispatched agencies as well as the two trauma centers in Missoula were able to view the 
PSAP CAD screen ‘live’ over the internet via CAD Status software. This software automatically 
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updates displays at the response agencies every 30 seconds.** CAD Status capability is 
important as it provides the mechanism which allows near real-time sharing of the OnStar 
AACN information with emergency response services and receiving hospitals. 


Activity at MESI Ground Ambulance Base. Missoula Emergency Services, Inc. (MESI) is the 
local ground ambulance provider. Test participants from MESI included Matt Bierer (paramedic) 
who participated from the Burlington Avenue ambulance base, and Don Whalen (MESI 

Regional Manager) who was at Community Medical Center. Rebecca Gao from the University of 
Montana, acted as the observer for the research team during the test call. Marie Flanigan 
(CUBRC) met briefly with MESI staff before and after the test call. 


Activities at MESI are shown in box ‘2’ on the left side of Figure 12. Paramedic Matt Bierer 
received the alert for the OnStar test call on his pager. Using his ToughBook (laptop) computer 
with CAD Status, he observed the AACN information as it was posted on the PSAP screen 
shows the information displayed (see Figure 15). The data viewed by the paramedic in the field 
using the Toughbook, is also viewed by MESI staff on the desktop computer at the MESI base. 


After a few minutes, Paramedic Bierer placed a phone call to the charge nurse at Community 
Medical Center and provided a (simulated) patient en route status report. The report to the charge 
nurse contained the usual patient medical information (i.e., vitals, injuries, and treatments). In 
addition, he reported to the charge nurse the patient was in an OnStar crash and the patient was 
an occupant of the Chevy Malibu (determined from test call script). He also reported a rollover 
had occurred, impact was from the right, ISP was HIGH, (delta) velocity was 25 mph, and time 
of alert (to OnStar) was 10:23 am. Note: This ’time of alert’ provides the best estimate of ‘time 
of injury’, which is useful information for medical providers. 


** CAD Status can be installed on any computer that supports JAVA and has high-speed internet access. If an agency 
is connected to CAD Status, they have the ability to print the ‘call for service’ data as it is ongoing (See “Montana’s 

Motor Vehicle Crash Data Infrastructure”, MT AACN Project Task 1 Report, Amanda Golbeck, Kathy Humphries, 

Julie Stevens, April 30, 2010). 
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INCIDENT NUMBER : MC050312-116 


INCIDENT CODE : 362 

INCIDENT DESC : VERICLE-Personal Injury 
LOCATION : 7938 GRANT CREEK R&D 

Cross Streets : PARKWOOD DR * 7700-7998 OLD GRANT CREEK RD 
BUSINESS $ 

CALLER : onstar 

CURRENT PHONE : (800) 888-1234 

RESIOENCE PHCNE 3 

ENTERED : 05/03/12 10:22:35 BY PHONES:110 
DISPATCHED : 05/03/12 10:25:02 BY FMA:s9 

OX SCENT 3 

COMPLETED : 05/03/12 10:28:37 

PRIORITY 3 1 


DESK REFERENCE INFORMATION: 


COMMENTS : 

[10:25:55 Pager} Successfully paged: CITY FIRE 

(10:24:36 PHONES:110] OP CHRIS 

(10:24:18 PHONES: 110) TIME ALERT 1023 

{10:24:12 PHONES:110} ROLLOVER YES 

[10:24:07 PHONES:110) DIR IMP1 FROM THE RIGET 

(10:23:58 PHONES: 110) DV1 25 MPH Advancing 
(10:24:41 Pager] Successfully paged: MESI ‘ 
(10:23:44 PHONES:110} mimp NO v oY PavGh Time 
(10:23:38 PHONES:110) ISP HIGE 

(10:23:30 PHONES:110} CASE 125489017 

[10:23:19 PHONES:110] UNKN 2ND VEK 

[10:23:11 PHKONES:110] CHEVY MALIBU 

[10:23:05 PHONES:110) 2 PPL INJUREO UNKN FURTHER 

[10:22:54 PHONES:110] Inc Address changed to 7938 GRANT CREEK RD at 10:23 

[10:22:47 PHCNES:110)] 2 VEHS 


[10:22:41 PHONES:110) TEST CALL <————__ Start Test Call 
OTHER RESPONDING APPARATUS AND AGENCIES: 

UNIT STATUS AGENCY DATE/TIME 

c10 DISP . MISSOULA POLICE DEPARTMENT 05/03/12 10:25:02 

141 DISP =e City Fire 05/03/12 10:25:02 

111 DISP @ <& City Fire 05/03/12 10:25:02 

110 oDIsP > 8 City Fire 05/03/12 10:25:02 

crs DISP 7 & City Fire 05/03/12 10:25:02 

MEDL DISP oo Missoula Emergency Services 05/03/12 10:25:02 

LF DISP < TO HELICOPTER 05/03/12 10:25:07 : 
MEDL EN_ROUTE Missoula Emergency Services 05/03/12 10:26:01 Advancing 
C19 AVAIL MISSOULA FOLICE DEPARTMENT 05/03/12 10:27:34 Time 
141 AVAIL City Fire 05/03/12 10:27:36 

111 AVAIL City Fire 05/03/12 10:27:37 

110 AVAIL City Fire 05/03/12 10:27:39 

cr4 AVAIL City Tire S$/O3/12 10:27343 

MEDI AVAIL Missoula Emergency Services 08/03/12 10:27:45 

LF AVAIL HELICOPTER 05/03/12 10:27:47 


Figure 15. CAD Status Data as Displayed at MESI 


Activity at Community Medical Center. Community Medical Center (CMC) is a Level 3 Trauma 
Center in Missoula. Test call participants at Community included Jonathan Stred (Supervisor, 
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CMC Emergency Services), Kristina MacGrady (Health Unit Coordinator), and the charge nurse 
on duty. Traci Jasnicki (Trauma Coordinator) briefly stopped by as did Don Whalen (MESI) and 
Philip Richards (Flight Paramedic, Careflight). Marie Flanigan (CUBRC) was the research team 
observer at CMC during the call. 


The major test call activities at Community are summarized in box ‘3’ of Figure 12. The test call 
activities took place at the nurse’s station in the Emergency Department where the Charge Nurse 
and Health Unit Coordinator each had a desk. The Health Unit Coordinator typically monitors 
the CAD Status screen (among other duties), while the charge nurse is the usual recipient of the 
phone or radio call from the en route ambulance. If the charge nurse is away from her desk when 
a call comes in, the Health Unit Coordinator answers the call and pages the charge nurse. 


Several minutes were spent providing the coordinator and the charge nurse with a summary of 
the test call objectives and their individual roles in the test activities. The importance of 
acquiring and recording the ISP and the make/model of the patient vehicle during the en route 
call from the ambulance was emphasized. 


At 10:22 a.m., the CAD Status main screen on the Health Unit Coordinator’s computer displayed 
a single line indicating that an incident involving a vehicle occurred on Grant Creek Rd. Note: 
There are no ‘active’ blinking or audio alerts when a new call is posted; however, the health unit 
coordinator periodically checks the CAD Status screen. The coordinator clicked on the new 
record and the details of the test ‘call for service’ were displayed along with the additional 
OnStar parameters. These parameters were noted and discussed. The data displayed on the CAD 
Status screen at CMC is identical to that observed at MESI and shown previously in Figure 15. 


A few minutes later, a phone call from the MESI paramedic simulating the en route call from the 
ambulance was received at the charge nurse’s station. The call was initially answered by the 
coordinator who paged the charge nurse. The charge nurse returned to her desk, spoke to the 
medic and completed the CMC ‘EMS Report’ form. This form has a column for medical patients 
where History, Presentation, Vitals and Treatment (HPVT) are listed, and a column for trauma 
patients where Mechanism, Injury, Vitals and Treatment (MIVT) are listed. Figure 16 shows this 
form along with the notes regarding the simulated OnStar crash taken by the charge nurse during 
the phone call from the MESI medic. In addition to the usual notations for age, gender, etc., the 
notes include ‘OnStar’, ‘Rollover’, ‘70 mph’, ‘Impact R’ (Right), ‘Time 10:23’, ‘ISP High’ and 
‘Chevy Malibu’. The key information on the ISP and the make/model of the patient vehicle were 
successfully noted. It is also apparent that with the significant level of activity in the ED, the 
charge nurse experienced some difficulty hearing (e.g., ‘Roll-over was first written as ‘Pole’ then 
corrected, and the delta velocity was not accurately recorded.) It is expected problems with voice 
communications over the radio or phones are not uncommon in this environment, due to 
background noise at the scene, in the ambulance or in the ED. This actually highlights an 
additional benefit of having the data available electronically in the ED on the CAD Status screen 
since this provides an alternate source to quickly verify information. 
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Figure 16. EMS Report Completed by Hospital Charge Nurse at CMC 
3.4.3 Activity at Life Flight and St Patrick’s Hospital Emergency Room 


Life Flight is based at St. Patrick’s Hospital, which is the Level 2 Trauma Center in Missoula. 
Test call participants from St. Patrick’s and Life Flight included John Bleicher, RN (St. Patrick’s 
Trauma Coordinator) and Larry Peterman, RN (Chief Flight Nurse, Life Flight). Observers from 
the research team included Alan Blatt (CUBRC) and Grace Silvia (University of Montana). 


The activities at St. Patrick’s Hospital, shown in box ‘4’ on the right side of Figure 12, occurred 
in two locations within the hospital. The initial location was at the Life Flight office on the 
seventh floor of the hospital, co-located with the flight crew facilities and the helipad. 
Subsequent activities took place at the charge nurse’s station in the Emergency Department. 


Life Flight - The demo began at St. Patrick’s Life Flight office with the arrival of a dispatch 
notice on Larry Peterman’s pager. This notice came from the Life Flight (MedStar) 
Communications Center in Spokane, Washington. Spokane dispatch does not routinely speak to 
Missoula 9-1-1; Spokane sends Life Flight a text page of the pertinent information they received 
from Missoula 9-1-1. The Life Flight crew also received a voice page from the Missoula PSAP. 


Only a selected subset of the information available on the CAD Status display and/or transmitted 
by the Missoula PSAP to the Life Flight Communications Center was transmitted and displayed 
on the pager. This is because the protocol for dispatch of an air medical service dictates detailed 
information on the nature of the incident should not be provided until after the pilot conducts 
weather and flight safety checks and accepts the flight. This is to avoid undue pressure on the 
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pilot to accept a mission if weather conditions indicate that the flight is not advisable. 
Information received on the pager for the test call included identification of the emergency as an 
OnStar car crash, the crash location, and arbitrarily selected data such as DV1. No information 
on the OnStar vehicle make and model or the Injury Severity Prediction (ISP) value was 
provided on the pager. 


The CAD Status display was observed by the research team and stakeholder participants on the 
computer at the St. Patrick’s Life Flight office. CAD Status is also displayed at the Spokane 
Communications Center. 


The next step in the demonstration was to wait a few minutes after the dispatch was received and 
then have the flight nurse simulate the call that would typically be made by radio from the 
helicopter en route to the receiving hospital with information on the arriving patient. For the 
purposes of the test call, it was assumed the Life Flight crew had been able to identify their 
patient as having been an occupant of the OnStar equipped vehicle and they also had been 
advised of the other available OnStar related information (e.g. ISP). The flight nurse placed the 
call to the St. Pat’s charge nurse and provided her with the typical information on injury 
mechanism (car crash, ejection, etc.), patient injuries/vital signs, treatments provided by the 
flight crew, and the OnStar related crash information, including the make/model of the patient 
vehicle. 


After the call was made, the participants and observers all went from the Life Flight office to the 
charge nurse’s station in the Emergency Department (where CAD Status can also be viewed) to 
see how the information had been recorded and to discuss how it could be associated with the 
incoming patient record. 


St. Patrick’s Hospital ER - In the Emergency department, it was noted en route information 
provided by the flight nurse was simply written by the hospital charge nurse in a ‘free form’ 
format on a sheet of paper. Figure 17 shows the information recorded as part of this 
demonstration. This is typical of all en route information provided by ambulances and 
helicopters coming to St. Patrick’s. 


51 


lO” 
; a > ‘ 
“ e coe ft Ay 4 Wee 


SO my \ < 7 ’ , 0 
. 8 ~. WN <> ¥ Lent v Dat 


ls , 
VAAA TS 


SP Sic 


o 
~ 
~~ 


a wih 


Figure 17. St. Patrick Hospital Charge Nurse Notes 
3.4.4 Post Test Feedback and Actions 


Feedback from participating stakeholders and observers is provided below, divided into three 
categories: 1) Real Time Operations, 2) Education and Training, and 3) Linkage and 
Documentation. More detailed discussion on these topics can be found in the full test call report 
(Flanigan et al., 2012). 


Feedback Related to Real Time Operations. Both EMS and hospital providers indicated 
abbreviations used for a number of the AACN parameters were too cryptic. Terms must be easily 
read and interpreted in real time. 


The paramedic indicated ‘Airbag Status’ (deployed, not deployed) would be useful to know at 
time of dispatch. This information was subsequently added to the requested AACN parameters. 
Note: a crash impact from the rear will not usually trigger an air bag deployment although an 
AACN alert can still be sent. 


It is clear cooperation will be required amongst police, first responders, and EMS to ensure the 
make/ model of patient vehicle is communicated in a timely way to EMS personnel transporting 
that patient. It was suggested knowing the color of the OnStar car might help medics quickly 
assess if patient was in the OnStar car. 


The flight nurse suggested either the Life Flight Base in Missoula or the Communications Center 
in Spokane could provide flight crew with AACN information from CAD Status during flight to 
scene. The MESI paramedic indicated strong interest in receiving (at time of dispatch) any 
available information on potential number of injured via CAD Status. Note: This information is 
available only if OnStar Advisor is able to talk with vehicle occupants. 
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Given that for an injury crash, EMS is simultaneously dispatched and usually gets to the scene 
before police, the possible use of ISP to identify crashes NOT requiring a police ‘lights and 
sirens’ response (i.e., 1f ISP=LOW) was raised by a police stakeholder. 


Finally, given that background noise can occasionally make it difficult for the hospital charge 
nurse to clearly hear the EMS report over radio or phone, having access to the AACN data via 
CAD Status in the ED, provides an alternate source to confirm information on the crash event. 


Feedback Related to Education/Training. There was interest expressed by emergency 
responders in seeing data on crash delta velocity and how it might relate to the likelihood of 
serious injury. There was also a request for a clear explanation of ‘crash delta velocity’. Finally, 
a question was raised regarding differences between the AACN data provided via CAD Status 
and data obtained from the Event Data Recorder (EDR) by police crash investigators. 
Clarifications on these topics were subsequently provided to participants in a document entitled 
“Response to Questions on Crash Delta-V, Probability of Serious Injury, EDRs, and AACN”, 
Memo to Montana Stakeholders Participating in MT AACN May 3, 2012 Demonstration (Blatt; 
Flanigan, 2012). 


Feedback Related to Data Linkage/Documentation. The Emergency Services Supervisor at 
Community Medical Center requested all AACN data (including patient vehicle make/model and 
ISP) be documented on the current en route EMS Report form in ‘Mechanism of Injury” box (see 
Figure 16). This form is routinely scanned into the patient hospital record, which ensures capture 
of information needed to appropriately link crash data and patient injury data. 


The Trauma nurse coordinator at St Patrick’s suggested a simple form could be developed for 
use by the charge nurse when recording information on OnStar crashes, including make/model of 
patient vehicle. The completed form could be placed in the patient folder, which will provide 
sufficient information to link the OnStar data to the patient record. In addition, the CAD Status 
screen containing the OnStar data could be printed from the ER display and placed into the 
patient record. 


It was noted AACN parameters were presented clearly on the website. One hospital stakeholder 
suggested data is posted on the website within 24 hours as this makes the data available during 
the early days of trauma patient treatment. This request will be considered along with inputs 
from the PSAP regarding frequency of AACN data download from the PSAP database. The 
website map showing crash location was thought to be a useful addition for inclusion in the pre- 
hospital ground ambulance patient care report (PCR). 
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3.4.5 Post Test Follow Up 


In response to the feedback received, the research team and the PSAP together developed 
simplified terminology, which eliminates some of the abbreviations for AACN parameters 
entered into CAD Status. For any injury accident where OnStar calls the 9-1-1 PSAP, the call 
taker will pose the following questions (column 1) and document it in the CFS Comment field as 
shown in column 2: 


Question Posed to OnStar Sample Answers & Format for 
Advisor by PSAP Call Taker Entry into CFS Comment Field 

e What is ISP? ISP High 

e Vehicle Make/Model? Chevrolet Malibu 

e Multiple Impacts? Multi Impact No 

e Delta Velocity? Delta V1 25 mph 

e Direction of Impact? DIR IMP 1 from Left 

e Rollover? Rollover Yes 

e Time of Alert? Time Alert 1023 

e Airbag Deployed? Airbag Yes 


OnStar was alerted on June 14, 2012, the Missoula PSAP was ready to ‘go live’ with collection 
of OnStar call data. OnStar had previously agreed to respond to questions from the Missoula 
PSAP regarding AACN data elements*’. On the PSAP boundary map for Missoula, OnStar 
placed a note the Advisor sees, explaining Missoula operators may ask for ISP (High/Low) and 
the Advisor should provide that information along with other crash parameters (Airbag 
Deployment, Delta V, Direction of impact, Multiple Impacts, and Rollover). 


As previously described, in order to archive AACN data, so that it is later accessible by medical 
providers and trauma system researchers, a process was established by Missoula PSAP IT 
personnel to run an automated script once a week that scans the Missoula PSAP database for any 
OnStar calls during the previous week. The PSAP then emails an Excel data file to CUBRC. 
After beta testing (July), the Missoula PSAP began sending CUBRC a regular weekly email 
(beginning Aug 6, 2012) which contained all calls from OnStar in the preceding week. This 
weekly extract is automatically processed by customized software developed at CUBRC which 
reads the file and uploads OnStar call records to the (password protected) MT AACN Database 
at https://montana-aacn.cubrc.org. If no OnStar calls are received, a NULL (empty) Excel file is 
still emailed to CUBRC. 


Currently, all calls from OnStar are uploaded to the database. This includes ‘Good Samaritan’ 
calls (where an OnStar subscriber pushes the SOS button to get help for another party) as well as 
SOS calls (where an OnStar subscriber needs assistance but a crash is not involved or the crash 
was minor (below the AACN threshold)). Good Samaritan/SOS calls populate just a few fields in 
the call record (“CFS Number’, possibly ‘TSP Case ID’, ‘TSP Caller Name’ (OnStar), ‘PSAP 
Call Time’ and ‘Event Location’. If a call is an ACN call (from an aftermarket FMV system or 
an old ACN system, the ‘Airbag Deployed’ field will also be populated and perhaps ‘Time of 
Alert’. Only AACN calls will populate ‘Delta V’, ‘Direction of Impact’, ‘Rollover’, ‘Multiple 


*> Jeff Joyner (OnStar) email message to authors, June 10, 2011. 
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Impacts’ and ‘ISP’. The only way to determine if a record in the MT AACN database is an 
AACN call is if these latter fields are populated. 


Over a 30-week period, eight OnStar calls from Missoula County came into the Missoula PSAP. 
Of these, four were Good Samaritan calls (OnStar subscriber not involved) and four were SOS 
calls (button push). There have been no AACN calls thus far. This was a bit surprising since 
Missoula County was expected to receive about 10 AACN calls in a year (based on historical 
data from OnStar that 100 AACN calls occurred the previous year in Montana). One 
interpretation is the 100 AACN calls were actually 100 emergency calls that OnStar passed on to 
the PSAP. If the latter, this 100-call figure would include Good Samaritan and SOS calls. 
Regardless, CUBRC will continue to monitor the weekly extracts using the automated process 
described above. When sufficient AACN calls are acquired, the process will be revisited and will 
possibly screen out the Good Samaritan and SOS calls (assuming MT stakeholders concur). In 
the meantime, uploading all OnStar calls including the Good Samaritan and SOS calls provides 
confirmation that the automated process is working. 


Two documents were prepared which describe the MT AACN website. The first is a User’s 
Guide, which explains the functionality provided to an end user of the MT AACN web 
application. This application provides a mechanism for archiving telemetry data in the MT 
AACN Database, as well as providing a portal for registered users to view the data post-event. 
The website is also set up to support a registration process to provide username and password 
access to authorized users. The User’s Guide is provided in Appendix D. The second document 
is a technical document (written for a System Administrator with SQL / database experience), 
which explains how to setup and deploy the MT AACN web application on a new system 
(Fusillo 2013). It is anticipated the web application will eventually be set up on a server at MT 
DPHHS. 


3.5 Conclusions and Recommendations 


During the test call, all required OnStar AACN data were successfully entered into the PSAP 
CAD system and displayed to responding agencies and hospitals within two minutes of the initial 
9-1-1 call. The collection of the simulated AACN data did not delay dispatch of emergency 
services since a separate dispatcher began this process while the call taker continued to collect 
the additional AACN data. 


CAD Status, which is routinely used by emergency providers in Missoula, was shown to be a 
viable mechanism for sharing AACN data with EMS responders and hospital providers in near 
real time. CAD Status is refreshed every 30 seconds. 


The results of this test showed in order to support the use of the OnStar data for field triage and 
later research activities, only small changes to existing protocols and procedures are necessary to 
ensure the required data is captured and made available for use in Missoula. For example, both 
ground and air EMS responders demonstrated a mechanism to view or hear AACN information 
while en route to the scene (i.e., via Toughbook for ground EMS and via radio communication 
for air EMS). Thus, AACN information could be used to support field decisions as appropriate. 
Both ground and air medical responders successfully communicated ISP and the make/model of 
the patient’s vehicle to the hospital charge nurse during the EMS (simulated) en route report on 
patient status. Charge nurses at both hospitals accurately recorded vehicle make/model and ISP 
using their normal documentation procedures for EMS en route information. They also had real 
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time access to the CAD Status display. A hard copy of the EMS report and a printout of the CAD 
Status screen (with the AACN data) were obtained from both hospitals as test documentation. 
Mechanisms were identified at each hospital to ensure the AACN data in CAD Status (and the 
patient vehicle make/model information) were associated with the patient hospital record, 
thereby enabling appropriate linkage of crash event data with patient injury data. 


One key finding of the project was the critical need to identify at the scene, which patient came 
from which vehicle and to communicate this information to the EMS provider so that OnStar 
crash information (especially ISP) is associated with the correct patient. This requirement is 
manageable with sufficient training of first responders, police, and EMS providers. For example, 
police routinely include make/model of the crashed vehicles in the Police Accident Report. Thus, 
there is no change in this data collection requirement, only that the vehicle information be noted 
sooner and communicated to EMS at the scene. The first page of the EMS Patient Care Report 
(PCR) form usually contains mechanism of injury and vehicle information fields. Make/model of 
the patient vehicle can be documented here by EMS and shared with the charge nurse at the 
hospital during the en route EMS report. 


Finally, the simple and inexpensive approach described here for getting AACN information in 
real time to emergency medical providers (by using manual data entry into the PSAP Comment 
field, giving dispatched agencies access to AACN data via CAD Status and subsequent archiving 
of AACN data via an automated process), could be implemented in any county which has CAD 
Status or similar software. A number of PSAPs in Montana currently uses this software. The 
approach provides a viable interim solution until all crash telemetry data is transmitted 
electronically from OnStar (or any TSP) to the PSAP. The following the implementations are 
recommended: 


e Operation of the system implemented in Missoula should be continued. It is quite 
surprising no OnStar crash calls were received by the Missoula PSAP during the 
project. The available historical data from OnStar indicates several crashes involving 
OnStar equipped vehicles resulting in calls to the Missoula PSAP should be expected. 
By continuing the Missoula implementation, it will be possible to demonstrate the 
system performance and benefits when future crash calls arrive. 


e Review the OnStar call history at other Montana PSAPs. Implement the ‘Missoula 
system’ at one or more of the PSAPs that have a history of receiving OnStar crash 
calls. By establishing new implementations it will be possible to evaluate the 
performance of the system at other Montana PSAPs. The steps required to implement 
this system are straightforward: 

> To ensure a pathway forward, the PSAP should have VOIP capability and 
Wireless Enhanced 911 established to support Priority Access. Stage 1 
Priority Access is currently implemented in 46 of the 57 PSAPs in 
Montana. 

> The PSAP must have CAD Status software installed which allows any 
designated hospital or agency dispatched by the PSAP to view emergency 
calls ‘live’ as the incident is unfolding. CAD Status can be installed on 
any computer that supports JAVA and has high-speed internet access. 

>» PSAP personnel must be instructed to request AACN data from the 
OnStar Advisor when an AACN crash occurs. PSAP personnel must also 
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be trained to manually enter this data into the PSAP ‘Comment’ field 
using prescribed data element names. 

>» The software script to extract and forward OnStar AACN calls from the 
PSAP database to the MT AACN Database must be executed at pre- 
determined (e.g., weekly) intervals at the PSAP. This script can be 
obtained from the Missoula PSAP. 

>» Education of first responders, EMS, and hospital personnel regarding the 
use of AACN data and injury severity prediction must be undertaken. In 
particular, the need for identifying make and model of the OnStar patient 
vehicle at the scene and the reasons why this information must be 
immediately shared with EMS and the receiving hospital charge nurse, 
should be conveyed to all responding emergency personnel. 

> Once sufficient AACN crashes are logged in Montana (and perhaps 
combined with AACN events from other western states), research should 
be initiated to help further validate the injury severity prediction 
algorithms as well as evaluate the use of other AACN data to improve real 
time patient triage, treatment, and transport decision-making. 


Implementing this interim process to enable real time sharing of crash telemetry data with the 
medical response community will provide educational benefits to MT PSAP and emergency 
services personnel even though AACN events are infrequent. This will prepare them to fully 
utilize crash telemetry and injury prediction information as AACN technology becomes standard 
in more vehicles and as AACN data becomes available electronically in all PSAPs (i.e., via Stage 
3 Priority Access or Next Generation 911 implementation). 
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4 Survey of Emergency Department Participation in MT’s Resource 
Facilitation Service 


Each year, many Montanans acquire a brain injury from a car crash, sports injury, fall, stroke, or 
other cause. Even mild brain injuries can lead to significant functional loss and problems of 
adjustment. The Brain Injury Association of Montana’s (BIAMT) goal is to assist individuals 
who experience acquired brain injury to adjust effectively and to lead successful lives. 
Accordingly, BIAMT offers a Resource Facilitation Service (RFS) to everyone who experiences 
a brain injury in Montana. Resource Facilitation (RFS) is a service that links individuals with 
traumatic brain Injury (TBI) and their families to local information, resources, service providers, 
and natural supports. RFS is designed to benefit patients and to reduce demands on hospital staff 
due to repeat visits. RFS is offered free of charge to patients for as long as two and a half years. 


BIAMT has sought to expand its Brain Injury Resource Facilitation Program referral network 
across the State. The adoption and participation of hospital emergency departments has been 
uneven, however. This may be due to a number of factors. Researchers sought to assess the 
potential for expanding it by conducting a survey of the Montana hospital emergency 
departments to assess their awareness of the program, the extent of their participation in the 
program, and certain other aspects of their operation. This survey was designed to provide a 
foundation for BIAMT’s planning outreach to hospitals and to increase the patients served. 


4.1 Methods 


4.1.1 Participants 


Researchers worked with staff of the Department of Public Health and Human Services to 
develop a contact list of hospital emergency department coordinators in Montana. They secured 
the email addresses for the coordinators. A staff member of BIAMT called each hospital to 
verify the contact information. Researchers identified 53 Montana hospitals with ED 
coordinators. 


4.1.2 Procedures 


BIAMT staff and members of the research team developed a survey and protocol with 
consultation from a Trauma Coordinator of a large hospital that participates in the RFS program. 
Two members of the research project technical panel who expressed specific interest in helping 
shape the content of this survey reviewed this survey. It was also submitted to the entire 
technical panel and approved by the University’s Institutional Review Board. 


The brain injury survey was distributed to the trauma coordinator or emergency room director of 
53 Montana hospitals by e-mail. Researchers alerted potential participants to the on-line survey 
by sending an e-mail that described the research and indicated another e-mail would follow with 
a link to the survey. The e-mail with the link was sent approximately a week later. That e-mail 
indicated participants could provide information by using the link or by participating in a phone 
interview. Non-respondents and non-completers were sent a reminder e-mail. 


4.2 Results and Findings 


Sixty-one coordinators were identified to participate. Researchers were unable to e-mail 12 so 
contacted them by phone to obtain an e-mail address. Because of this effort, an additional four 
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links to the survey were emailed. Finally, after another week, non-respondents were contacted by 
phone to remind them to complete the on-line survey. Researchers achieved a 76% response rate 
(40 surveys that were completed or started divided by 53 successfully delivered e-mail 
notifications). The following reports on the usable information provided by 32 respondents. 


Table 5 lists the number of responding hospital EDs by Montana Trauma Facility Designation. 
Despite contacts with many EDs, only four indicated that they already participated in the RFS 
program. 


Table 5. Responding Hospital Emergency Departments 


Regional Trauma Area Trauma Hospital Trauma Receiving > 

Center (n=3) (n=3) Facility (n=9) UO al) 

*Billings Clinic *Bozeman Deaconess «Barrett Hospital and *Blackfeet Community 
Hospital HealthCare Hospital 


*St. Patrick Hospital and 


Health Sciences *Kalispell Regional *Beartooth Hospital and *Broadwater Health 
*St. Vincent Healthcare Medical ene Ecalth Crates *Colstrip Medical 
St. James Healthcare *Liberty medical Center *Crow/Northern Cheyenne 
*NEMHS Poplar Hospital aah Meniaial 


Philips County Hospital 
*Pondera Medical Center 
*Powell County Hospital 


Roosevelt Medical Center 


Healthcare Assoc. 
*Fallon Medical Complex 
*Fort Belknap Service 


¢Frances Mahon 


St. Joseph Medical Deaconess Hospital 


Center *Granite County Medical 
Center 


«Madison Valley Medical 
Center 


*McCone County Health 
Center 


*Northern Rockies 
Medical Center 


*Rosebud Health Care 
*Ruby Valley Hospital 


¢Sheridan Memorial 
Hospital 


Stillwater Community 
Hospital 


*St. Luke Community 
Hospital 


Figure 18 shows the estimate of the average number of patients with head trauma and patients 
with head trauma from car crashes treated annually. Respondents estimated they treated 50,593 
patients emergency rooms annually. Of those who were treated in emergency rooms, 
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approximately 3,796 (7.5%) of patients have a head trauma or brain injury due to any cause (e.g., 
car crash, sports injury, fall, stroke, etc.). Of those who were treated in the emergency room with 
a head trauma or brain injury, approximately 887 (23%) sustained the head trauma or brain 
injury in a car crash. 


Average Number of Patients 
Number of Patients with Head Trauma 
Number of Patients with Head Trauma From Car Crash 
Treated Annually 
B Average @ With Head Trauma Head Trauma From Car Crash 
28,333 
16,000 
1,966 —— 
1,890 ss4 1,333 494 7)" 234 29 Mm 29 133 
== = =a —— 
Regional Trauma Center Area Trauma Hospital Trauma Receiving All Other 
Facility 


Figure 18. Average number of patients with head trauma from car crashes 


From a systems perspective, BIAMT must judge what is understood as brain injury for each ED. 
This is reflected to some extend by the tools used to assess it. Table 6 presents the tools used to 
screen for brain injuries. While clinical assessment provides a flexible assessment, the Glasgow 
Coma Scale emphasizes injuries that are more serious. Few of the EDs reported using other 
scales that target specific causes. This suggests that BIAMT should emphasize the importance of 
considering any level of brain injury as suitable for referral; not just the most serious. 
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Table 6. Tools Used for Brain Injury Screening 


Hospital Tools Used 

Designation 

ey ; Hospital Glasgow Acute Spor 

respondents) ene rat t Check Coma Concussion a a ae Other anes 
List Scale Evaluation Tool 

Regional 0 

Trauma 3 1 3 0 0 1 

Center (n=3) 

Area Trauma 0 

Hospital 3 1 3 0 0 1 

(n=3) 

Trauma 0 

Receiving 9 1 9 2 1 1 

Facility (n=9) 

All Other 0 

(n=17) 17 3 17 3 1 0 


Table 7 shows the circumstances in which ED staffs are likely to screen patients for brain 
injuries who come either by medical transport or as walk-ins. Again, the likelihood of screening 
increases with severity. This underscores the importance of the message BIAMT needs to convey 
about who should be referred to the RFS. 


Table 7. Staff likely to Screen for Brain Injury 


Likely to Screen 


: Hit Head No Hit Head : : : 
Minor : j Unconscious Unconscious a Unconscious Always 
Chaat Complaints or Complains or : : : 
Injuries <1 Minute Few Minutes >5 Minutes Screen 
Problems Has Problems 
Regional 
Trauma 1 1 2 3 3 3 0 
Center (n=3) 
Area 
Trauma 
Hospital : 2 : . : : u 
(n=3) 
Trauma 
Receiving 
Facility 3 5 8 9 9 9 1 
(n=9) 
All Other 
(n=17) 6 9 17 16 16 16 2 
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Table 8 shows the knowledge level of emergency room staff with the signs and symptoms for 
identifying potential mild brain injury (1=not knowledgeable, 5=very knowledgeable). This 
suggests that BIAMT might offer training to bolster their outreach program. 


Table 8. Knowledge of the Signs and Symptoms 


Hospital Designation ee wes 
(n=total # survey respondents) Gres nangentes) 
Regional Trauma Center (n=3) 2.5 (2) 

Area Trauma Hospital (n=3) 4.0 (3) 

Trauma Receiving Facility (n=9) 3.1 (9) 

All Other (n=17) 3.5 (17) 


Table 9 shows the likely referral pattern for each level of brain injury severity across hospital 
designations. This suggests BIAMT might concentrate its outreach efforts for serious injuries on 
the larger hospitals where more serious injuries are treated but educate the smaller hospitals 
about the importance of referring individuals with relatively mild injuries. 


Table 9. Likely Referral Patterns 


Severe 
Hospital Designation [eS ee ee eS 
Treat | Transfer | Both | Transfer Destination 
(n=total # survey respondents) 
(# Providing Destination Information) 
Regional Trauma Center (n=3) 2 0 0 N/A 
Area Trauma Hospital (n=3) 1 2 0 Great Falls (1) 
Trauma Receiving Facility (n=9) | 0 8 1 Not Provided 
All Other (n=17) 0 17 0 Great Falls (1), Idaho Falls (1), Kalispell 
(2) 
Hospital Designation Moderate Transfer Destination 
(n=total # survey respondents) | Treat | Transfer | Both | (## Providing Destination Information) 
Regional Trauma Center (n=3) 2 0 0 N/A 
Area Trauma Hospital (n=3) 1 2 0 Great Falls (1) 
Trauma Receiving Facility (n=9) | 2 6 1 Not Provided 
All Other (n=17) 1 12 4 Great Falls (1), Idaho Falls (1), Kalispell 
(2) 
Minor 
Hospital Designation ee 
Treat | Transfer | Both | Transfer Destination 
( n=total # survey respondents) 
(# Providing Destination Information) 
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Regional Trauma Center (n=3) 2 0 0 N/A 
Area Trauma Hospital (n=3) 3 0 0 N/A 

| Trauma Receiving Facility(n=9)|8 [0 [1 |NotProvided  ~*'| 
All Other (n=17) 12 4 1 Not Provided 


Table 10 shows the Regional Trauma Centers were very familiar with RFS. The Area Trauma 
Hospitals were significantly less familiar and the small facilities were barely familiar at all. 
Again, if BIAMT wants to increase its services to those with severe injuries, they should 
concentrate on maintaining referral relationships with the larger hospitals. If they want to 
increase the total number of people reached, they should provide much more education to the 
smaller hospitals where milder injuries are treated but not referred. 


Table 10. Familiarity with RFS 


: : : Familiarity 
Hospital Designation feel 
(n=total # survey respondents) (# respondents) 


Regional Trauma Center (n=3) 4.5 (2) 
Area Trauma Hospital (n=3) 3.7 (3) 
Trauma Receiving Facility (n=9) —-:1.9 (9) 
All Other (n=17) 1.3 (17) 


Again, this underscores the willingness of hospital staff to refer patients. What seems to be 
missing is a clear and sustainable mechanism for them to do so. Table 11 shows that all 
respondents were willing to very willing to refer patients when they suspect a patient’s 
complaints may involve a mild brain injury - whether or not the patient is not admitted to the 
hospital. 
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Table 11. Willingness to Refer patients 


Willingness 
Hospital 1=Unwilling 2 3 4 5=Very Willing 
lore Not Is Not Is Not Is Not Is Not Is 
survey ee om | amit eee OME | 4 anit (ne ee 
respondents) 
Regional 0 0 0 0 1 0 0 1 1 1 
Trauma Center 
(n=3) 
Area Trauma 0 0 0 0 1 0 1 2 1 1 
Hospital (n=3) 
Trauma 1 0 0 1 3 3 1 1 4 4 
Receiving 
Facility (n=9) 
All Other 0 0 0 0 6 4 6 3 5 10 
(n=17) 


4.3 Discussion 


The finding that only four EDs report participating in the RFS program underscores the gap in 
awareness about the services. Yet, almost all EDs were willing to very willing to refer patients; 
even those with mild injuries who are not admitted to the hospital. 


BIAMT should consider their strategic position in relation to their resources. There appear to be 
at least three options. First, BIAMT could emphasize services to those with severe injuries. This 
would involve focusing attention on the larger hospitals to which the smaller EDs refer and 
transfer patients with more severe injuries. This would concentrate their resources and reach 
those with the most need. Second, BIAMT could seek to reach those with mild injuries but this 
would require expanding outreach to many more of the smaller hospitals. Third, BIAMT could 
seek resources to support an expansion to all hospitals and provide services to many more 
individuals. 


Researchers recommend that BIAMT focus attention on the three largest hospitals to address 
those most in need and to capture the largest patient population. If BIAMT can work out the 
procedures for sustaining consistent levels of referral and providing minimal services, they may 
be able to argue for resources to expand the RFS to a broader population. 
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5 Expanding the Brain Injury Referral Network 


The emphasis on response to injuries from motor vehicle crashes typically focuses on immediate 
care from the point of the event through medical treatment at a clinic or hospital. A public health 
model takes a broader view; a view that spans the time from crash events through rehabilitation 
and community reintegration. Of course, not everyone who experiences injury from a motor 
vehicle crash is transported for medical treatment. Emergency responders (or occupants of a 
crashed vehicle) may not recognize when to refer an individual for medical care, especially when 
seemingly mild or occult (hidden) injuries occur. Further, even those with serious injuries who 
receive medical care and in-patient rehabilitation do not always make a smooth transition back 
into their community. 


In one of the few population-based studies on the issue, Shults et al. (2004) estimated 1.2 million 
adults were living in the community with disabilities associated with motor vehicle crashes. 
Forty-one percent of those reported loss of work due to disability. Many individuals involved in 
crashes experience injuries that lead to long-term disability (Ameratunga et al., 2004). 
Surprisingly, these injuries need not appear to be severe to have significant consequences 
(Richmond et al., 2003; Myou et al., 1997). One of the injury groups that has been studied is the 
group with traumatic brain injuries (TBI). Studies have shown follow-up in the community after 
the injury can improve outcome (Wade, 2006). 


Consistent with public health prevention goals, it is expected disabilities associated with motor 
vehicle crash injuries can be reduced by early detection of those crash-related injuries that might 
lead to disabilities and by improving the coordination, tracking, and delivery of community 
rehabilitation and integration services for crash victims. To accomplish this, there is a need for a 
mechanism to identify and track motor vehicle crash victims with the potential for disability so 
they can be effectively matched with rehabilitation providers in their area and follow up support 
provided on a continuing basis. 


One model for identifying and tracking individuals who sustain injuries is the Resource 
Facilitation Service of the Brain Injury Association of Montana (BIAMT).”° This developing 
model is based on national guidelines for services to people with brain injury. It is a low-cost, 
telephone- and computer-based public health service that promotes identifying brain injury early, 
educating survivors and families about TBI, and supporting survivors to get timely treatment and 
rehabilitation. Currently, only five of Montana’s hospitals with EDs participate at any significant 
level. This project explored the procedures for expanding the RFS referral network. 


5.1. Methods and Procedures 


BIAMT staff used a standard program description approach to present their program to hospital 
staff. This involved describing the nature of traumatic brain injury (TBI) and the general 
consequences people experience. The RFS services were explained and the presenter invited 
referrals to the BIAMT from the hospital. This same approach was used in the first presentations 
to State and Regional Trauma Care Committees (STCC) through October 2009. This approach 
had not produced the level of referrals desired and was not well received by the STCC or RACs. 


*6 The Resource Facilitation Service (now the Brain Injury Help Line) of the Brain Injury Association of Montana (BIAMT) 
provides information and referral, and tele-counseling to individuals with brain injury across Montana. 
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Further, the members expressed concerns such presentations were to review case studies as 
learning and improving opportunities for first responders and emergency department staff. 
Concerns were expressed about HIPPA compliance if non Trauma/EMS personnel participated 
in the meetings. Also, it was mentioned participants in the meetings focus on stabilizing patients 
not additional treatments and rehabilitation needs. 


In response, the presentation was modified to be consistent with the “case review” approach 
typically used in medical settings and favored by the Trauma Advisory Committees. Ms. Morgan 
and Bobbi Perkins, a member of BIAMT’s Board of Directors, developed a presentation in the 
case study format to which Trauma Committees are accustomed. The presentation reviews the 
initial injury data but continues reviewing the post injury care and outcomes. The goal of the 
presentation is to increase awareness of post injury impact and how the Resource Facilitation 
Service can benefit individuals living with brain injury and their families; all levels of severity. 
The goal of the presentation was to increase the number of referrals made by hospitals by 
increasing awareness of post injury needs and the free service available to help patients return. 
The initial presentation to the State Trauma Care Committee (STCC) was made November 3, 
2009. This new presentation was positively received. Ms. Perkins reported that, overall, meeting 
participants were very supportive of connecting patients, especially mild traumatic brain injury 
(TBI) to RFS. For some STCC meeting participants, it was the first they had heard of RFS in 
Montana and they requested more information. Others knew about the program but did not feel 
they had materials they could hand out to patients in the emergency departments (ED). A few 
others regularly give out the RFS materials and encourage the patients to contact RFS. 


The group discussed that the ED is an important location to provide the patient and family 
information on RFS. The group also discussed a better model is to provide the patient’s name 
and contact information to RFS and let RFS contact the patient vs. expecting the patient to make 
the call to RFS on their own. The group discussed including, as part of the current hospital 
meetings, training on how to talk to patients/families about concussion /mild TBI (to reduce 
anxiety) and making a strong connection that follow-up calls to the physician’s office /ED 
regarding minor symptoms and concerns will be reduced by getting the patient hooked into RFS 
early. Additional presentations to RTCS were planned. Overall, BIAMT staff made presentations 
to the four RTACs and STCC. These led to invitations to visit and discuss RFS from six 
hospitals between February and April 2010. 


5.1.1 Data and Analysis 


Researchers used the data recorded by BIAMT to track the progress in referrals and services. 
These included data on the date of injury, cause of injury, date of referral, referral source, and 
selected demographic variables. Researchers examined the overall referrals rates, those from 
hospitals, and those with injuries due to a motor vehicle crash. 


5.2 Findings 


From January 2007 through December 2011, BIAMT received 793 referrals that were enrolled 

into the RFS program; an average of 158.6 per year. Hospitals accounted for 527 (66.5%) of all 
referrals. Figure 19 shows the total referrals and those from hospitals enrolled by year. Overall, 
referrals increased over these five years increased and increased significantly (t=.05) from 2010 
to 2011. However, despite the emphasis on adding hospitals to the referral process beginning in 
November 2009, there was no change in the overall referral rate from hospitals. A three-year 
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forecast at the current rates suggests total enrollments might reach 250 per year; with 
approximately 175 of those coming from hospitals. 


Total Enrollment By Year 
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Figure 19 . Total and hospital referrals enrolled in the RFS by year. 


Figure 20 presents the overall enrollments by month. Two points appeared to be outliers - month 
38 and month 59 — and were removed. The curvilinear trend highlights referral rates declining 
over the first year followed by a gradual increase over the last 20 months. Hospital recruitment 
through the trauma system began in month 34. 


Overall Enrollment by Month 
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Figure 20. Total referrals enrolled by month 


Figure 21 shows the cumulative referral pattern from hospitals to RFS. A total of 527 referrals 
were received from hospitals over the five year period. The cumulative graph shows a steady rate 
of referrals from hospitals. While there may be a trend toward growth over the last three months, 
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there is no difference between 2009 and 2010; after participation in the trauma groups. The 
difference appears to be coming from another source. 


Cumulative Referrals from Hospitals 
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Figure 21. Cumulative referrals from hospitals 


Figure 22 shows referrals from each hospital participating in the referral network. St. Vincent’s 
hospital was the major contributor over the five years. Five hospitals account for the vast 
majority of referrals, including: St Vincent’s, New Hope, Kalispell Regional, Billings Clinic, and 
Community Medical Center. Ten hospitals provided three or fewer referrals. Similarly, the 
Veterans hospital made no referrals during the period. 


Referrals By Hosiptals Across Years 
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Figure 22. RFS referrals from each hospital each year 


These efforts focused on brain injuries sustained in motor vehicle crashes. Figure 23 shows the 
cumulative referrals involving a brain injury due to a MVC — a total of 217 (41% of hospital 
referrals; 27% of all referrals). A total of 108 referrals were received over the first 34 months. 
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One hundred and nine referrals were received over the final 24 months. However, not all such 
referrals for brain injury associated with an MVC came from a hospital. 


Cummulative Referrals from 
Car Crashes 


oe 
© 
re 
= 
L 
3) 
[a 


1 5 9 13 17 21 25 29 33 37 41 45 49 53 57 


Months 


Figure 23. Cumulative referrals for brain injuries associated with MVC 


Figure 24 shows referrals from hospitals for injuries sustained in MVCs across the five years. 
The BIAMT received 161 referrals from hospitals. The effort to market the RFS through the 
Trauma Committees began in November 2009. While it appears this may have had an effect 
when viewed on an annual basis, a closer examination suggests that it did not. A three-year 
forecast suggests , at this rate, hospital referrals for car crashes will reach only about 52 per year. 


Hospital Referrals for Motor Vehicle Crashes 
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Figure 24. Annual referrals from hospitals for MVC 
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Figure 25 shows the cumulative referrals from hospitals across months. When examined against 
a linear trend line, the rate of hospital referrals varies but does not suggest a deviation from the 
relative rate. 


Cumulative Hospital Referrals for 
MVC 
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Figure 25. Cumulative hospital referrals for TBI from MVC's 


Figure 26 shows that the hospital referral sources for individuals injured in motor vehicles 
crashes parallels that for all injuries. That is, the top five referral sources accounted for the 
majority of referrals (St. Vincent’s, New Hope, St. Patrick’s, Kalispell Regional, and Community 
Medical Center). Little variation appears. 
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Figure 26. Referrals from hospitals over each of the five years 


While being referred for assistance at all is a critical step, the time between an injury and 
enrollment for services can influence outcome. Figure 27 shows the relationship between time to 
referral and the sequence or order in which individuals injured in motor vehicle crashes were 
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referred. The time to referral for those injured in motor vehicle crashes declined rapidly over the 
first 50 referrals, stabilized across the next 175 cases, and then began to rise again. Still, while 
the time to referral for MVC s averaged 32.5 days, the median is 70 day. The longest delay from 
the time of reported injury to referral exceeded 30 years. 
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Figure 27. Time from injury to referral for successive enrollees 
Figure 28 shows the sources of referrals that exceed the median. By far the greatest source (33%) 
is from an “other” than usual source. The Veterans Administration is the second highest source 
of delayed referrals (18%). 
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Figure 28. Source of referrals exceeding the median 


Figure 29 projects the delay in referral for the next 100 cases at the current pace. This analysis 
suggests that referrals will continue to come from people who were injured several years ago. 
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Figure 29. Projection of increase in delayed referrals 


5.3 Discussion 


Over the five years beginning in 2007, BIAMT received 793 referrals that were enrolled into the 
RFS program; an average of 158.6 per year. Hospitals accounted for 527 (66.5%) of all referrals. 
Of all hospital referrals, 161 were for brain injuries due to a MVC. 


An increase in referrals over time and an increase in referrals from hospitals for brain injuries 
related to MVCs were found. However, those do not seem to have been related to the outreach 
conducted through the STCC and RTCCs. This growth in referrals between 2010 and 2011 may 
be explained in part by an increase in public education about concussions from sports activities, 
self-referrals by veterans, and referrals by community agencies. 


While the outreach to the STCC and RTCCs led to hospital presentations of revised materials, 
BIAMT did not develop or implement procedures to establish formal mechanisms of referral and 
follow-up with those hospitals. BIAMT may still want to consider doing so. 


In the emerging era of bundled and outcome reimbursement for medical treatment and hospital 
care, such an arrangement could lead to reimbursement for services under contract from a 
hospital. If BLIAMT can demonstrate their RFS services reduce unnecessary re-hospitalization, 
for example, it becomes a valuable service for cost containment. 


The time to referral after injury varied considerably and may be increasing. Overall, the time to 
referral for MVC s averaged 32.5 days, the median was 70 days. A total of 321 cases exceeded 
the median. The major source of those “delayed” referrals was other than not a standard source. 
However, the VA accounted for 18%. BIAMT might consider an outreach campaign that used 
themes such as: 


1. It’s Never Too Late 

When You’re Ready, We Can Help 

The Sooner the Better 

How Long Has It Been? 

Don’t Hesitate to Ask - Don’t Hesitate to Tell 


ode i 
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In any case, BIAMT might want to reconsider their approach to establishing and maintaining 
referrals from hospitals. The same five hospitals appear to be responsible for the majority of 
hospital referrals. St. Vincent’s and New Hope contribute the most by far. One possible new 
strategy, reflecting the practice of St. Vincent’s, would be to negotiate the inclusion of a standard 
referral prompt as hospitals adopt and implement electronic medical record systems. 


73 


6 Estimating the Costs of a Brain Injury 


6.1 Referral Network 


The Resource Facilitation Service (now the Brain Injury Help Line) of the Brain Injury 
Association of Montana (BIAMT) provides information and referral, and tele counseling to 
individuals with brain injury across Montana. The BIAMT receives referrals from many sources 
but hospitals are the place that those with a significant injury go for help. BIAMT currently 
provides the only statewide system for follow-up information and referral for individuals 
experiencing brain injury. While this system is in an early phase of development and is limited to 
brain injury, it provides a model upon which a more comprehensive system of patient follow-up 
could be designed. One question is how much might it cost to expand this model? This study 
attempted to estimate the costs of providing this service more broadly. 


6.2 Method 


Two researcher team members interviewed the director of the BIAMT and reviewed budget 
records. They identified the tasks required to sustain the Help Line, amount of time each task 
required, salary levels of each staff involved, and the current level of activity and service. These 
data were placed in a spreadsheet and the calculations confirmed by testing against actual 
figures. Then, based on the data from the study reported above, a series of scenarios were 
conducted to estimate the budget required to support services at different levels. Table 11 present 
the results compared to the current budget; which received about 222 referrals in the last full 
year. 


Table 12. Projected Budgets 


Current Projected Projected Projected Projected 
Budget Referrals Referrals Referrals Referrals 
(N= 222) (N=200) (N=222) (N=300) —(N=444) 
Budget at 
Levels of $113,000 $139,385 $140,325 $143,659 $149,814 
Referral 
Difference 


from Current $0 ($26,385) ($27,325) ($30,659) ($36,814) 


The estimated range of cost for doubling referrals and serving 444 referrals annually ranges from 
$149,418 to $160,510. Specific budget line time totals for the lower estimate of serving 444 
individuals each year included: $44,354 for referral services, $42,006 in labor costs, $53,204 in 
supplies and facility overhead, and $10,250 in travel. 


6.3 Discussion 
This analysis suggests the Brain Injury Help Line may be underfunded by as much as $27,235 
annually at this point in its development. If the service doubled by expanding recruitment for 


referrals or expanded to include individuals with serious injuries from car crashes, it could be 
operated for the modest $150,000 to $160,000 annually. 
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Alternatively, rather than seeking to expand referrals, BIAMT may reduce their scope to match 
their budget. One option would be to reduce their effort to include all hospitals and focus on 
those that are the source of referrals already. 


One question that remains to be addressed is the cost benefit of the Help Line. BIAMT might 
consider conducting a study of the outcomes of referral services to build a case for funding. 
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Appendix A - Technical Panel Test Call Participants and Stakeholders 


Research Project Technical Panel 


Name Position Organization 


Jim DeTienne EMS & Trauma Systems Section DPHHS 
Supervisor 


Tom Hamilton Captain 

Pierre Jomini Traffic Safety Engineer 
Ryan Olson Former Montana State 9-1-1 MT Dept. of Admin 

Program Assistant Manager 

Steve Albert TI 

Phil Balsley Traffic and Safety Bureau DT 


Jake Boltz Montana Highway Patrol 
Calvin Schock Montana Highway Patrol 
Steve Keller Communications Bureau 


Nels Sanddal Critical Illness & Trauma 
Marcee Allen 
Max Sevareid 


Key Informants 


Name Position Organization 
Jim DeTienne EMS & Trauma Systems DPHHS 
Section Supervisor 
Tom Hamilton Captain MT Highway Patrol 
Pierre Jomini Safety Management Engineer | MT DOT 
Ryan Olson Former Montana State 9-1-1 MT Dept. of Admin 


Program Assistant Manager 
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Test Call Participants and Stakeholders 


Name Affiliation Email Test Call Station Station Location 

Blatt, Alan CUBRC blatt@cubrc.or St Patrick’s ED or | 500 W Broadway 
Flight Room 

Bierer, Matt MESI emtibierer@msn.com MESI Dispatch 1200 Burlington 

Bleicher, John St Pat’s Hospital jbleicher@saintpatrick.org St Patrick’s ED or | 500 W Broadway 
Flight Room 

Christensen, Kris | MDT krchristensen@mt.gov MDT Helena 

Costilla, Valerie Univ of MT veostilla@ruralinstitute.umt.edu PSAP 200 W Broadway 

DeTienne, Jim MT DPHHS jdetienne@mt.gov MT DPHHS Helena 

Flanigan, Marie CUBRC flanigan@cubre.org Community ED 2827 Fort 

Missoula Road 

Fusillo, Tom CUBRC fusillo@cubre.org CUBRC Buffalo, NY 

Goe, Rebecca Univ of MT rgoe@ruralinstitute.umt.edu MESI Dispatch 1200 Burlington 

Grimes, Shane Montana Highway sgrimes@mt.gov PSAP 200 W Broadway 

Patrol 

Jeff Joyner OnStar Jeffrey. Joyner@ONSTAR.com OnStar Detroit 

Lounsbury, Chris | Missoula PSAP clounsbury@co.missoula.mt.us PSAP 200 W Broadway 

Peterman, Larry LifeFlight (St Pat’s) PETERMAN@saintpatrick.org Life Flight 500 W. Broadway 
Flight Room 

Seekins, Tom Univ of MT ruraldoc@ruralinstitute.umt.edu PSAP 200 W Broadway 

Silvia, Grace Univ of MT Grace.silvia@umontana.edu Life Flight 500 W Broadway 
Flight Room 

Stred, Jon Community Medical | jstred@communitymed.org Community ED 2827 Fort 

Center Missoula Road 
Weber, John Missoula City Police | jweber@ci.missoula.mt.us PSAP 200 W Broadway 
Whalen, Don MESI don@missoulaparamedics.com MESI Dispatch 1200 Burlington 
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Appendix B - Seven Agencies’ Data Flow Diagrams 
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Appendix C - Data Book 


88 


VEDS OnStar MSO 9-1- EMS OPHI-PCR Police and Hwy Patrol SmartCop Hwy Patrol Trauma ; Hospital 
1 Sheriff CAD Call Hx SmartCop Crash Discharge & ED 
R Com R Com Re Com Comme Re Com 
ef Name Ref ment ef ment Ref Comment f ment Ref nt Ref Comment f ment Ref Comment 
Data Source 1.1 
Type 3 
Incident 
Originator 4 
4 
Provider Name 5 3 3 109, 112, 201 
4 
Incident ID 3 Crash 2, 
Number 6 3 115 3 3 2 Report # 7 2 
Call Back 4 
Number 7 4 30 110 
Incident Data 1.2 
4 
Event Verified 0 
4 
Incident Date 3 
and Time 3 63 
Received 
Date/Time of 10, Admission 
Incident 11 143 5 116, 117 3 date 
5 
Event Time 5 140 4 
2 6- 6 
Location 3 215-223 7 91,92 17-19 2 
81 
2 , 
Latitude 12 3 218 83 91 17 
82 
2 , 
Longitude 13 3 218 83 92 18 
58 
13 
6, 4- 
Location 2 7, 51-65, 67-92, 13 
Description 15 3 215-223 10 216-217 19 9 
Data Book 89 


Datum 


14 


51 


LDT Confidence 


LDT Confidence 
Percentage 


Location Time 


VEDS 


OnStar 


MSO 9-1- 


EMS OPHI-PCR 


Police and 
Sheriff 


Hwy Patrol SmartCop 


CAD Call Hx 


Hwy Patrol 
SmartCop Crash 


Trauma 


Hospital 
Discharge & ED 


Device Event 
Type 


Agency Notified by 
Voice 1.3 


16 


Name 


Reference 
Number 


Agency 
Telephone 
Number 


Agency Contact 
Address 


Agency Contact 
Time 


Automated Incident 
Data 1.4 


Data from the 
Vehicle 1.4a 


Vehicle Data 


Body Type 


~N 


98 


174 


USDOT # 


290 


Manufacturer 


18 


Make 


19 


97 


181 


Model 


20 


PHANIWAN 


182 


Data Book 


90 


6 
Year 21 0 96 180 
13 
Weight 9 304 categorical 
2 
6 
Color 22 5 184 
Power Source 
2 
6 
License Plate 1 179 
2 
6 
VIN 23 6 173 
Owner Data 
1 
5 218- 
Owner's Name 0 221 
1 
5 
Owner's Age 7 
1 
Owner's 5 
Gender 2 
Owner's 
Language 


Owner Hearing 
Impaired 


Owner Mobility 
Impaired 


Owner Speech 
Impaired 


Owner Other 
Condition 


Data 


Primary Driver 


Primary 
Driver's Age 


Data Book 


91 


Primary 
Driver's Gender 


Primary 
Driver's 
Language 


Primary Driver 
Hearing 
Impaired 


Primary Driver 
Mobility 
Impaired 


Primary Driver 
Speech 
Impaired 


the 


Primary Driver 
Other 
Condition 


Other Data from 


Vehicle 


Owner's State 
and Province 


a 


94 


176 


Garaged State 
and Province 


24 


Hazardous 
Materials 


307 


Veh 


Contents of 


icle 


Contents 
Quantity 


Crash Data 1.4b 
General Crash 
Data 


Ignition State 


Heading 


28 


wWwwalwwa 


10 


66 


216 


Orientation 


30 


Data Book 


92 


Fire 


243 


Multiple 
Impacts 


30 


WwWAWWA 


244 


241- 
255 


descriptives 


Impacts 


Delta Velocity 


26 


Crash Pulse 
Duration 


Crash Pulse 
Location 


Principle 
Direction of 
Force 


Rollover 


27 


29 


244 


Digital image 
location 


Seat Data 


Seat 


Airbag Deployed 


Deployed 


33 


Each 
airbag 


248 


15 


88 


Location 


34 


Other Seat Data 


Belt Monitored 


Belt Fastened 


247 


15 


86 


10 


Tensioner 
Triggered 


Occupied 


Post Crash On Scene 
Data 1.5 


Data Book 


93 


General Post 


Crash Data 
4 
Number of 3 
Occupants 3 213 
Occupant 
15 
5, 13 
15 : 
1 6, 23 
Occupant's 5 15 - 
Name 0 153-155 7 96-99 25 
1 
5 15 
Occupant's Age 7 166, 167 9 108 50 
1 
Occupant's 5 15 
Gender 2 163 8 109 48 
19 
4 6- 
3 296-300, 19 
Conscious 3 303 9 
19 
4 252, 2- 
3 292- 19 
Breathing 3 293, 307 3 
4 
3 
Speaking 3 303 
4 
3 317, 
Moving Arm 3 337, 339 
4 
3 319, 
Moving Leg 3 338, 340 
4 
External 3 
Bleeding 3 323-342 
4 
3 15 20 
Entrapped 3 261 4 151 8 
4 
3 15 
Ejected 3 243 3 89 
Data Book 94 


Seat Position 


32 


Ww 


245 


14 


82-85 


Child Seat 


Restraint Type 


10 


Child Weight 


Injury Patterns 


Seat Type 


Latch Used 


247 


10 


Historical (Personal) 


Medical Data 1.6 


Provider 


Provider 
Retrieval 
Method 


Provider 
Telephone 
Number 


Provider Fax 


Provider URL 


Record Update 
Date 


Subscriber 


Info 


rmation 


Name 


Age 


Gender 


Language 
Hearing 
Impaired 


Mobility 
Impaired 


Speech 
Impaired 


Data Book 


95 


Other 
Condition 
Primary Care 
Physician 
Name 264-266 
Telephone 
Number 
Emergency 
Contact 
Presence 
Name 278 of form 
Telephone 
Number 
Alternate TN 
Other Subscriber 
Information 
Medical Injured 
History 270 Person's 
Injured 
Allergies 268, 269 | Person's 
Injured 
Medications 274-277 Person's 
Blood Type 
Injured 
Pregnant 280 Person 
Organ Donor 
Preferred 
Hospital 
Injured 
Living Will 267 Person's 
Subscriber 
Government IDs 
Driver's License Injured 
Number 171 Person's 
Driver's License Injured 
State Province 170 Person's 
Social Security Injured 
Number 162 Person's 
Data Book 96 


Subscriber Primary 
Insurance Provider 


Insurance Injured 
Provider Name 174 Person's 


Injured 
Policy Number 181 Person's 


Telephone 

Number 
Frequent Drivers/ 

Occupants (FDO) 


FDO Age 


FDO Gender 


FDO Language 


FDO Hearing 
Impaired 


FDO Mobility 
Impaired 
FDO Speech 
Impaired 


FDO Other 
Condition 


Data Book 


Line # | Category # Group Category Sub-Category Element 

2 1.1 Data Source Data Source Data Source Type 

3 1.1 Data Source Data Source Data Source Incident Originator 

4 1.1 Data Source Data Source Data Source Provider Name 

5 1.1 Data Source Data Source Data Source Incident ID Number 

6 1.1 Data Source Data Source Data Source Call Back Number 

7 1.2 Incident Data Incident Date, Time, Incident Date, Time, Event Verified 
Location Location 

8 1.2 Incident Data Incident Date, Time, Incident Date, Time, Incident Date and Time 
Location Location 

9 1.2 Incident Data Incident Date, Time, Incident Date, Time, Received Date/Time of 
Location Location Incident 

10 1.2 Incident Data Incident Date, Time, Incident Date, Time, Event Time 
Location Location 

11 1.2 Incident Data Incident Date, Time, Incident Date, Time, Location 
Location Location 

12 1.2 Incident Data Incident Date, Time, Incident Date, Time, Latitude 
Location Location 

13 1.2 Incident Data Incident Date, Time, Incident Date, Time, Longitude 
Location Location 

14 1.2 Incident Data Incident Date, Time, Incident Date, Time, Location Description 
Location Location 

15 1.2 Incident Data Incident Date, Time, Incident Date, Time, Datum 
Location Location 

16 1.2 Incident Data Incident Date, Time, Incident Date, Time, LDT Confidence 


Data Book 


98 


Line # | Category # Group Category Sub-Category Element 
Location Location 
17 1.2 Incident Data Incident Date, Time, Incident Date, Time, LDT Confidence Percentage 
Location Location 
18 1.2 Incident Data Incident Date, Time, Incident Date, Time, Location Time 
Location Location 
19 1.2 Incident Data Incident Date, Time, Incident Date, Time, Device Event Type 
Location Location 
20 1.3 Agency Notified by Agency Notified by Voice Agency Notified by Voice Name 
Voice 
21 1.3 Agency Notified by Agency Notified by Voice Agency Notified by Voice Reference Number 
Voice 
22 1.3 Agency Notified by Agency Notified by Voice Agency Notified by Voice Agency Telephone Number 
Voice 
23 1.3 Agency Notified by Agency Notified by Voice Agency Notified by Voice Agency Contact Address 
Voice 
24 1.3 Agency Notified by Agency Notified by Voice Agency Notified by Voice Agency Contact Time 
Voice 
25 1.4a Automated Incident Data from the Vehicle Vehicle Data Body Type 
Data 
26 1.4a Automated Incident Data from the Vehicle Vehicle Data USDOT # 
Data 
27 1.4a Automated Incident Data from the Vehicle Vehicle Data Manufacturer 
Data 
28 1.4a Automated Incident Data from the Vehicle Vehicle Data Make 
Data 
29 1.4a Automated Incident Data from the Vehicle Vehicle Data Model 


Data Book 


O9 


Line # | Category # Group Category Sub-Category Element 

Data 

30 1.4a Automated Incident Data from the Vehicle Vehicle Data Year 
Data 

31 1.4a Automated Incident Data from the Vehicle Vehicle Data Weight 
Data 

32 1.4a Automated Incident Data from the Vehicle Vehicle Data Color 
Data 

33 1.4a Automated Incident Data from the Vehicle Vehicle Data Power Source 
Data 

34 1.4a Automated Incident Data from the Vehicle Vehicle Data License Plate 
Data 

35 1.4a Automated Incident Data from the Vehicle Vehicle Data VIN 
Data 

36 1.4a Automated Incident Data from the Vehicle Owner Data Owner's Name 
Data 

37 1.4a Automated Incident Data from the Vehicle Owner Data Owner's Age 
Data 

38 1.4a Automated Incident Data from the Vehicle Owner Data Owner's Gender 
Data 

39 1.4a Automated Incident Data from the Vehicle Owner Data Owner's Language 
Data 

40 1.4a Automated Incident Data from the Vehicle Owner Data Owner Hearing Impaired 
Data 

41 1.4a Automated Incident Data from the Vehicle Owner Data Owner Mobility Impaired 
Data 

42 1.4a Automated Incident Data from the Vehicle Owner Data Owner Speech Impaired 

Data Book 100 


Line # | Category # Group Category Sub-Category Element 

Data 

43 1.4a Automated Incident Data from the Vehicle Owner Data Owner Other Condition 
Data 

44 1.4a Automated Incident Data from the Vehicle Primary Driver Data Primary Driver's Age 
Data 

45 1.4a Automated Incident Data from the Vehicle Primary Driver Data Primary Driver's Gender 
Data 

46 1.4a Automated Incident Data from the Vehicle Primary Driver Data Primary Driver's Language 
Data 

47 1.4a Automated Incident Data from the Vehicle Primary Driver Data Primary Driver Hearing 
Data Impaired 

48 1.4a Automated Incident Data from the Vehicle Primary Driver Data Primary Driver Mobility 
Data Impaired 

49 1.4a Automated Incident Data from the Vehicle Primary Driver Data Primary Driver Speech 
Data Impaired 

50 1.4a Automated Incident Data from the Vehicle Primary Driver Data Primary Driver Other 
Data Condition 

51 1.4a Automated Incident Data from the Vehicle Other Data from the Vehicle | Owner's State and Province 
Data 

52 1.4a Automated Incident Data from the Vehicle Other Data from the Vehicle | Garaged State and Province 
Data 

53 1.4a Automated Incident Data from the Vehicle Other Data from the Vehicle | Hazardous Materials 
Data 

54 1.4a Automated Incident Data from the Vehicle Contents of Vehicle Contents Quantity 
Data 

55 1.4b Automated Incident Crash Data General Crash Data Ignition State 

Data Book 101 


Line # | Category # Group Category Sub-Category Element 

Data 

56 1.4b Automated Incident Crash Data General Crash Data Heading 
Data 

57 1.4b Automated Incident Crash Data General Crash Data Orientation 
Data 

58 1.4b Automated Incident Crash Data General Crash Data Fire 
Data 

59 1.4b Automated Incident Crash Data General Crash Data Multiple Impacts 
Data 

60 1.4b Automated Incident Crash Data Impacts Delta Velocity 
Data 

61 1.4b Automated Incident Crash Data Impacts Crash Pulse Duration 
Data 

62 1.4b Automated Incident Crash Data Impacts Crash Pulse Location 
Data 

63 1.4b Automated Incident Crash Data Impacts Principle Direction of Force 
Data 

64 1.4b Automated Incident Crash Data Impacts Rollover 
Data 

65 1.4b Automated Incident Crash Data Impacts Digital image location 
Data 

66 1.4b Automated Incident Crash Data Seat Data Seat 
Data 

67 1.4b Automated Incident Crash Data Airbag Deployed Deployed 
Data 

68 1.4b Automated Incident Crash Data Airbag Deployed Location 


Data Book 
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Line # | Category # Group Category Sub-Category Element 

Data 

69 1.4b Automated Incident Crash Data Other Seat Data Belt Monitored 
Data 

70 1.4b Automated Incident Crash Data Other Seat Data Belt Fastened 
Data 

71 1.4b Automated Incident Crash Data Other Seat Data Tensioner Triggered 
Data 

72 1.4b Automated Incident Crash Data Other Seat Data Occupied 
Data 

73 1.5 Post Crash On Scene General Post Crash Data General Post Crash Data Number of Occupants 
Data 

74 1.5 Post-Crash On Scene Occupant Occupant Occupant's Name 
Data 

75 1.5 Post-Crash On Scene Occupant Occupant Occupant's Age 
Data 

76 1.5 Post-Crash On Scene Occupant Occupant Occupant's Gender 
Data 

77 1.5 Post-Crash On Scene Occupant Occupant Conscious 
Data 

78 1.5 Post-Crash On Scene Occupant Occupant Breathing 
Data 

79 1.5 Post-Crash On Scene Occupant Occupant Speaking 
Data 

80 1.5 Post-Crash On Scene Occupant Occupant Moving Arm 
Data 

81 1.5 Post-Crash On Scene Occupant Occupant Moving Leg 

Data Book 103 


Line # | Category # Group Category Sub-Category Element 

Data 

82 1.5 Post-Crash On Scene Occupant Occupant External Bleeding 
Data 

83 1.5 Post-Crash On Scene Occupant Occupant Entrapped 
Data 

84 1.5 Post-Crash On Scene Occupant Occupant Ejected 
Data 

85 1.5 Post-Crash On Scene Occupant Occupant Seat Position 
Data 

86 1.5 Post-Crash On Scene Child Seat Child Seat Restraint Type 
Data 

87 1.5 Post-Crash On Scene Child Seat Child Seat Child Weight 
Data 

88 1.5 Post-Crash On Scene Child Seat Child Seat Injury Patterns 
Data 

89 1.5 Post-Crash On Scene Child Seat Child Seat Seat Type 
Data 

90 1.5 Post-Crash On Scene Child Seat Child Seat Latch Used 
Data 

91 1.6 Historical (Personal) Provider Provider Provider Retrieval Method 
Medical Data 

92 1.6 Historical (Personal) Provider Provider Provider Telephone Number 
Medical Data 

93 1.6 Historical (Personal) Provider Provider Provider Fax 
Medical Data 

94 1.6 Historical (Personal) Provider Provider Provider URL 
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Line # | Category # Group Category Sub-Category Element 

Medical Data 

95 1.6 Historical (Personal) Provider Provider Record Update Date 
Medical Data 

96 1.6 Historical (Personal) Subscriber Information Subscriber Information Name 
Medical Data 

97 1.6 Historical (Personal) Subscriber Information Subscriber Information Age 
Medical Data 

98 1.6 Historical (Personal) Subscriber Information Subscriber Information Gender 
Medical Data 

99 1.6 Historical (Personal) Subscriber Information Subscriber Information Language 
Medical Data 

100 1.6 Historical (Personal) Subscriber Information Subscriber Information Hearing Impaired 
Medical Data 

101 1.6 Historical (Personal) Subscriber Information Subscriber Information Mobility Impaired 
Medical Data 

102 1.6 Historical (Personal) Subscriber Information Subscriber Information Speech Impaired 
Medical Data 

103 1.6 Historical (Personal) Subscriber Information Subscriber Information Other Condition 
Medical Data 

104 1.6 Historical (Personal) Primary Care Physician Primary Care Physician Name 
Medical Data 

105 1.6 Historical (Personal) Primary Care Physician Primary Care Physician Telephone Number 
Medical Data 

106 1.6 Historical (Personal) Emergency Contact Emergency Contact Name 
Medical Data 

107 1.6 Historical (Personal) Emergency Contact Emergency Contact Telephone Number 


Data Book 
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Line # | Category # Group Category Sub-Category Element 
Medical Data 

108 1.6 Historical (Personal) Emergency Contact Emergency Contact Alternate TN 
Medical Data 

109 1.6 Historical (Personal) Other Subscriber Other Subscriber Medical History 
Medical Data Information Information 

110 1.6 Historical (Personal) Other Subscriber Other Subscriber Allergies 
Medical Data Information Information 

111 1.6 Historical (Personal) Other Subscriber Other Subscriber Medications 
Medical Data Information Information 

112 1.6 Historical (Personal) Other Subscriber Other Subscriber Blood Type 
Medical Data Information Information 

113 1.6 Historical (Personal) Other Subscriber Other Subscriber Pregnant 
Medical Data Information Information 

114 1.6 Historical (Personal) Other Subscriber Other Subscriber Organ Donor 
Medical Data Information Information 

115 1.6 Historical (Personal) Other Subscriber Other Subscriber Preferred Hospital 
Medical Data Information Information 

116 1.6 Historical (Personal) Other Subscriber Other Subscriber Living Will 
Medical Data Information Information 

117 1.6 Historical (Personal) Subscriber Government IDs Subscriber Government IDs Driver's License Number 
Medical Data 

118 1.6 Historical (Personal) Subscriber Government IDs Subscriber Government IDs Driver's License State Province 
Medical Data 

119 1.6 Historical (Personal) Subscriber Government IDs Subscriber Government IDs Social Security Number 
Medical Data 

120 1.6 Historical (Personal) Subscriber Primary Subscriber Primary Insurance Provider Name 


Data Book 
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Line # | Category # Group Category Sub-Category Element 
Medical Data Insurance Provider Insurance Provider 

121 1.6 Historical (Personal) Subscriber Primary Subscriber Primary Policy Number 
Medical Data Insurance Provider Insurance Provider 

122 1.6 Historical (Personal) Subscriber Primary Subscriber Primary Telephone Number 
Medical Data Insurance Provider Insurance Provider 

123 1.6 Historical (Personal) Frequent Drivers/ Occupants | Frequent Drivers/ Occupants | FDO Age 
Medical Data (FDO) (FDO) 

124 1.6 Historical (Personal) Frequent Drivers/ Occupants | Frequent Drivers/ Occupants | FDO Gender 
Medical Data (FDO) (FDO) 

125 1.6 Historical (Personal) Frequent Drivers/ Occupants | Frequent Drivers/ Occupants | FDO Language 
Medical Data (FDO) (FDO) 

126 1.6 Historical (Personal) Frequent Drivers/ Occupants | Frequent Drivers/ Occupants | FDO Hearing Impaired 
Medical Data (FDO) (FDO) 

127 1.6 Historical (Personal) Frequent Drivers/ Occupants | Frequent Drivers/ Occupants | FDO Mobility Impaired 
Medical Data (FDO) (FDO) 

128 1.6 Historical (Personal) Frequent Drivers/ Occupants | Frequent Drivers/ Occupants | FDO Speech Impaired 
Medical Data (FDO) (FDO) 

129 1.6 Historical (Personal) Frequent Drivers/ Occupants | Frequent Drivers/ Occupants | FDO Other Condition 


Medical Data 


(FDO) 


(FDO) 
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Line # Po Sais Value noes : i VEDS Element 

1.1 Data Source 

3 Data Source Type B Telematics Service Provider X Type 

4 Incident Originator B TRUE X Incident Originator 

5 Provider Name B OnStar X Provider Name 

6 Incident ID B OnStar Case ID X Incident ID 

7 Call Back Number B OnStar Call Center 800 # X Call Back Number 
1.2 Incident Data 

9 X Event Verified 

10 Received Date A Date at which data is received into OCC X Date Stamp 

11 Received Time A Time at which data is received into OCC X Received Time 

12 Latitude A Latitude of incident X Latitude 

13 Longitude A Longitude of incident Xx Longitude 

14 Datum A GIS map projection scheme X Datum 

15 Location Description | B (Used to send incident state to help CARS route | x Location Description 

to the appropriate state webserver) 

16 Device Event Type A ACN, AACN, or SOS Xx Device Event Type 
1.4a Vehicle Data 

18 Manufacturer B General Motors X Manufacturer 

19 Make B Chevrolet, Pontiac, etc. x Make 

20 Model B Lumina, Cavalier, etc. x Model 

21 Year B Xx Year 
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Line # penne oe Value ee : ut VEDS Element 
22 Color B X Colors 
23 VIN B X VIN 
24 Garaged State B State where car is garaged X Garaged State 
1.4b Crash Data 
26 Delta Velocity B Delta-v for each impact (up to 2) Xx Delta velocity 
27 PDOF B PDOF for each impact (up to 2) X Principal direction of force (PDOF) 
28 Pre-crash Heading A Heading prior to event Xx Pre-crash heading 
29 Rollover A Rollover for each impact - yes or know if any X Rollover 
impact experienced a rollover - (value ascribed 
to the first impact) 
30 Multiple Impacts B True / false X Multiple impacts 
1.5 Seat Data 
32 Seat Position B (Needed to support airbag deployed) Xx Seat Position 
33 Airbag Deployed B True for each distinct airbag reported to be Xx Airbag deployed 
deployed 
34 Location B (Needed to support airbag deployed) Xx Location (of deployed airbag) 


Note: OnStar provided a data dictionary limited to VEDS elements. 
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Bue VED Cad Table Name Table DBTableName DBFieldName Description 
# element 

2 CadAddressTable cadaddrdb2 cadaddrdb2 cfs_numbr The CFS Number 

3 cadaddrdb2 cadaddrdb2 addr_pre Prefix of the Incident 
Address (NWSE...) 

4 cadaddrdb2 cadaddrdb2 addr_street Street Name of the 
Incident Address (Main, 
Elm, 42nd, ...) 

5 cadaddrdb2 cadaddrdb2 addr_suf Suffix of the Incident 
Address (NWSE...) 

6 cadaddrdb2 cadaddrdb2 addr_stype Type of street (Ave., 
Blvd., Rd., ...) 

7 cadaddrdb2 cadaddrdb2 addr_fullstreet Full name of Incident 
Address (Number Prefix, 
Street Name, Suffix, 
Street Type) 

8 cadaddrdb2 cadaddrdb2 addr_number Number associated with 
the Incident Address 

9 cadaddrdb2 cadaddrdb2 landmark Any landmark name 
associated with the 
Incident Address 

10 

11 CadBoundaryTable cadbnddb2 cadbnddb2 bnd_nmbr The CFS Number - 
Foreign Key into the 
cadcfsdb2 table 

12 cadbnddb2 cadbnddb2 bind_id The boundary 
description 

13 cadbnddb2 cadbnddb2 resp_level The response level of the 
boundary 

14 cadbnddb2 cadbnddb2 resp _code The Response code of 
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Bee Mee Cad Table Name Table DBTableName DBFieldName Description 
# element 
the boundary 
15 cadbnddb2 cadbnddb2 cfs_numbr The CFS Number 
16 cadbnddb2 cadbnddb2 bound_id The logical ID associated 
with the response level 
and response code of the 
boundary definition 
17 cadbnddb2 cadbnddb2 agency The Agency related to 
the boundary definition 
18 
19 CadCallForServiceTable cadcfsdb2 cadcfsdb2 cfs_arch Always "0001" 
20 cadcfsdb2 cadcfsdb2 cfs_numbr Call for Service (CFS) 
Number - Primary key 
21 cadcfsdb2 cadcfsdb2 priority Priority of the Incident 
Code 
22 cadcfsdb2 cadcfsdb2 inc_code Incident Code 
23 1.2 cadcfsdb2 cadcfsdb2 address Incident Address 
Location, 
Latitude, 
Longitude, 
Location 
Descriptio 
n 
24 cadcfsdb2 cadcfsdb2 landmark Landmark 
25 cadcfsdb2 cadcfsdb2 apt_number Any apartment number 
associated with the 
Incident Address 
26 cadcfsdb2 cadcfsdb2 city City of the Incident 
Address 
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Be VED Cad Table Name Table DBTableName DBFieldName Description 
# element 

27 cadcfsdb2 cadcfsdb2 address_x X-coordinate of the 
Address 

28 cadcfsdb2 cadcfsdb2 address_y Y-coordinate of the 
Address 

29 cadcfsdb2 cadcfsdb2 zonel Not filled 

30 cadcfsdb2 cadcfsdb2 zone2 Not filled 

31 cadcfsdb2 cadcfsdb2 addrtype Agency of the First 
matching boundary 

32 cadcfsdb2 cadcfsdb2 onbound Not filled 

33 cadcfsdb2 cadcfsdb2 bound1 Not filled 

34 cadcfsdb2 cadcfsdb2 bound2 Not filled 

35 cadcfsdb2 cadcfsdb2 bound3 Not filled 

36 cadcfsdb2 cadcfsdb2 bound4 Not filled 

37 cadcfsdb2 cadcfsdb2 alarm_no Any alarm associated 
with the Incident Address 

38 cadcfsdb2 cadcfsdb2 offr_cntct Officer contract? Yes or 
No 

39 cadcfsdb2 cadcfsdb2 line_number Phone Line; alt "Dispatch 
Cntr." for SCFC burn 
notification 

40 1.2 Event cadcfsdb2 cadcfsdb2 how_recd How the CFS was 

Verified received 

41 cadcfsdb2 cadcfsdb2 in_progres Is the CFS in progress? 
Yes or No 

42 cadcfsdb2 cadcfsdb2 call_taker Call taker who answered 


Data Book 


112 


the CFS 


pee tbe Cad Table Name Table DBTableName DBFieldName Description 
# element 
43 1.1 cadcfsdb2 cadcfsdb2 complainan Complainant’s name 
Provider 
Name 
44 1.1 Call cadcfsdb2 cadcfsdb2 curr_phone Complainant’s phone 
back # 
45 cadcfsdb2 cadcfsdb2 comp_addre Reporting Person's 
Address 
46 cadcfsdb2 cadcfsdb2 res_phone Complainant’s residence 
phone 
47 cadcfsdb2 cadcfsdb2 weapon Weapon associated with 
this CFS? 
48 cadcfsdb2 cadcfsdb2 dispatcher Dispatcher who 
processed this CFS 
49 cadcfsdb2 cadcfsdb2 priunit Primary unit attached to 
the CFS 
50 cadcfsdb2 cadcfsdb2 finaldisp Any Final Disposition 
attached to the CFS 
51 cadcfsdb2 cadcfsdb2 building Any building names 
associated with the 
incident location 
52 cadcfsdb2 cadcfsdb2 busname Any business names 
associated with the 
incident location 
53 cadcfsdb2 cadcfsdb2 stmp_rcvd Date and time the CFS 
was received 
54 cadcfsdb2 cadcfsdb2 time_rcvd Time the CFS was 
received 
55 1.2 Event cadcfsdb2 cadcfsdb2 TimeReceived Time the CFS was 


Data Book 


113 


Line 


VEDS 
element 


Cad Table Name 


Table 


DBTableName 


DBFieldName 


Description 


Time 


received 


cadcfsdb2 


cadcfsdb2 


dow_rcvd 


Day of the week the CFS 
was received 


57 


cadcfsdb2 


cadcfsdb2 


stmp_sent 


Date and time the CFS 
was sent to a dispatcher 


58 


cadcfsdb2 


cadcfsdb2 


time_sent 


Time the CFS was sent to 
a dispatcher 


59 


cadcfsdb2 


cadcfsdb2 


TimeSent 


Time the CFS was sent to 
a dispatcher 


60 


cadcfsdb2 


cadcfsdb2 


dow_sent 


Day of the week the CFS 
was sent to a dispatcher 


61 


cadcfsdb2 


cadcfsdb2 


stmp_disp 


Date and time a unit 
attached to a CFS first 
changed status to 
DISPATCHED 


62 


cadcfsdb2 


cadcfsdb2 


time_disp 


Time a unit attached to a 
CFS first changed status 
to DISPATCHED 


63 


64 


cadcfsdb2 


cadcfsdb2 


cadcfsdb2 


cadcfsdb2 


DispatchTime 


dow_disp 


Time a unit attached to a 
CFS changed status to 
DISPATCHED 


Day of the week a unit 
attached to a CFS first 
changed status to 
DISPATCHED 


65 


cadcfsdb2 


cadcfsdb2 


stmp_cenrt 


Date and time a unit 
attached to a CFS first 
changed status to EN 
ROUTE 
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Line 


VEDS 
element 


Cad Table Name 


Table 


DBTableName 


DBFieldName 


Description 


cadcfsdb2 


cadcfsdb2 


time_cenrt 


Time a unit attached to a 
CFS first changed status 
to EN ROUTE 


67 


cadcfsdb2 


cadcfsdb2 


cenrtTime 


Time a unit attached to a 
CFS first changed status 
to EN ROUTE 


68 


69 


cadcfsdb2 


cadcfsdb2 


cadcfsdb2 


cadcfsdb2 


dow_cenrt 


stmp_consc 


Day of the week a unit 
attached to a CFS first 
changed status to EN 
ROUTE 


Date and time a unit 
attached to a CFS first 
changed status to ON 
SCENE 


70 


cadcfsdb2 


cadcfsdb2 


time_consc 


Time a unit attached to a 
CFS first changed status 
to ON SCENE 


71 


72 


cadcfsdb2 


cadcfsdb2 


cadcfsdb2 


cadcfsdb2 


conscTime 


dow_consc 


Time a unit attached to a 
CFS first changed status 
to ON SCENE 


Day of the week a unit 
attached to a CFS first 
changed status to ON 
SCENE 


73 


cadcfsdb2 


cadcfsdb2 


stmp_cmpl 


Date and time the CFS 
was COMPLETED 


74 


cadcfsdb2 


cadcfsdb2 


time_cmpl 


Time the CFS was 
COMPLETED 


75 


cadcfsdb2 


cadcfsdb2 


CompletionTime 


Time the CFS was 
COMPLETED 
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Bae VED Cad Table Name Table DBTableName DBFieldName Description 
# element 

76 cadcfsdb2 cadcfsdb2 dow_cmpl Day of the week the CFS 
was COMPLETED 

77 cadcfsdb2 cadcfsdb2 stamp_att_any Always '9999-12-31- 
24.00.00.000000' 

78 cadcfsdb2 cadcfsdb2 tim_att_any Always '24.00.00' 

79 cadcfsdb2 cadcfsdb2 TimeAttAny Not filled 

80 cadcfsdb2 cadcfsdb2 dow_att_any Always " (blank) 

81 cadcfsdb2 cadcfsdb2 duration The difference between 
the time completed and 
the time received (in 
seconds) 

82 cadcfsdb2 cadcfsdb2 routetime The difference between 
the time sent and the 
time received (in 
seconds) 

83 cadcfsdb2 cadcfsdb2 disptime The difference between 
the time dispatched and 
the time sent (in 
seconds) 

84 cadcfsdb2 cadcfsdb2 Agency Agency of the unit 
attached to the CFS 

85 cadcfsdb2 cadcfsdb2 station The boundary 
description 

86 cadcfsdb2 cadcfsdb2 district The boundary 
description 

87 cadcfsdb2 cadcfsdb2 zone The boundary 
description 

88 cadcfsdb2 cadcfsdb2 map_page Map Page 
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Bue VED Cad Table Name Table DBTableName DBFieldName Description 
# element 

89 cadcfsdb2 cadcfsdb2 platoon Not filled 

90 cadcfsdb2 cadcfsdb2 cancelled Does the How Recd field 
contain the letter C? 

91 cadcfsdb2 cadcfsdb2 missing_times Complete with +1 for 
each of STMP_RCVD 

92 cadcfsdb2 cadcfsdb2 LinkIndex Index into the Links Table 
for RMS 

93 cadcfsdb2 cadcfsdb2 Floor Floor of the building 

94 cadcfsdb2 cadcfsdb2 XField1 Intoxicated 

95 cadcfsdb2 cadcfsdb2 XField2 Emergency Medical 
Description 

96 cadcfsdb2 cadcfsdb2 XField3 Varies by site; default 
label is "XField3:" but 
configurable in 
FieldNames.dat 

97 cadcfsdb2 cadcfsdb2 XField4 Varies by site; default 
label is "XField4:" but 
configurable in 
FieldNames.dat 

98 cadcfsdb2 cadcfsdb2 stmp_arch DateTime Archived 

99 cadcfsdb2 cadcfsdb2 time_arch Time Archived 

100 cadcfsdb2 cadcfsdb2 dow_arch DOW Archived 

101 cadcfsdb2 cadcfsdb2 inc_descript Incident Code 
Description 

102 cadcfsdb2 cadcfsdb2 Comp_x Complainant Address X 
coordinate 

103 cadcfsdb2 cadcfsdb2 Comp_y Complainant Address Y 


Data Book 


117 


Bue VED Cad Table Name Table DBTableName DBFieldName Description 
# element 

coordinate 

104 cadcfsdb2 cadcfsdb2 IncLatitude Incident Address Latitude 

105 cadcfsdb2 cadcfsdb2 IncLongitude Incident Address 
Longitude 

106 cadcfsdb2 cadcfsdb2 CompLatitude Complainant Address 
Latitude 

107 cadcfsdb2 cadcfsdb2 CompLongitude Complainant Address 
Longitude 

108 cadcfsdb2 cadcfsdb2 XField5 Extra fields - Not Filled 

109 cadcfsdb2 cadcfsdb2 XField6 Extra fields - Not Filled 

110 cadcfsdb2 cadcfsdb2 XField7 Extra fields - Not Filled 

111 cadcfsdb2 cadcfsdb2 Boundaryld Logical Boundary Id of 
the CFS Address; 
displayed in unlabeled 
boundary list 

112 cadcfsdb2 cadcfsdb2 Stmp_Strt SCFC Burn start time 

113 cadcfsdb2 cadcfsdb2 Time_Strt SCFC Burn start time 

114 cadcfsdb2 cadcfsdb2 Dow_Strt SCFC Burn start day of 
the week 

115 cadcfsdb2 cadcfsdb2 XField10 Extra fields - Not Filled 

116 cadcfsdb2 cadcfsdb2 XField11 Extra fields - Not Filled 

117 cadcfsdb2 cadcfsdb2 XField12 Extra fields - Not Filled 

118 cadcfsdb2 cadcfsdb2 XField8 Extra fields - Not Filled 

119 cadcfsdb2 cadcfsdb2 XField13 Extra fields - Not Filled 

120 cadcfsdb2 cadcfsdb2 XField9 Extra fields - Not Filled 
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Bue VED Cad Table Name Table DBTableName DBFieldName Description 
# element 

121 

122 CadCommandLineTable cadcomdb2 cadcomdb2 com_arch Always "0002" 

123 cadcomdb2 cadcomdb2 com_numbr The CFS Number - 
Foreign Key into the 
cadcfsdb2 table 

124 cadcomdb2 cadcomdb2 sequence Not filled 

125 cadcomdb2 cadcomdb2 stmp_creat Date and time the 
comment was attached 
to a CFS 

126 cadcomdb2 cadcomdb2 time_creat Time the comment was 
created 

127 cadcomdb2 cadcomdb2 dow_creat Day of the week the 
comment was created 

128 cadcomdb2 cadcomdb2 com_name Name of the user who 
attached the comment to 
the CFS 

129 cadcomdb2 cadcomdb2 com_ment Comment attached to a 
CFS 

130 cadcomdb2 cadcomdb2 cfs_numbr The CFS Number 

131 

132 CadDRNumberTable caddrndb2 caddrndb2 drn_arch Always "0004" 

133 caddrndb2 caddrndb2 drn_nmbr The CFS Number - 
Foreign Key into the 
cadcfsdb2 table 

134 caddrndb2 caddrndb2 d_agency The Agency associated 
with the DR Number 

135 caddrndb2 caddrndb2 dr_nmbr Desk Reference Number 
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Bue VED Cad Table Name Table DBTableName DBFieldName Description 
# element 
associated with a CFS 

136 caddrndb2 caddrndb2 stmp_att_drn Always '9999-12-31- 
24.00.00.000000' 

137 caddrndb2 caddrndb2 stmp_onsc_drn Always '9999-12-31- 
24.00.00.000000' 

138 caddrndb2 caddrndb2 stmp_ofsc_drn Always '9999-12-31- 
24.00.00.000000' 

139 caddrndb2 caddrndb2 resptime Always "-999" 

140 caddrndb2 caddrndb2 dr_duration Always "-999" 

141 caddrndb2 caddrndb2 cfs_numbr The CFS Number 

142 caddrndb2 caddrndb2 Unit Unit Associated with DR 
number 

143 

144 CadPersonTable cadperdb2 cadperdb2 per_arch Always "0006" 

145 cadperdb2 cadperdb2 per_nmbr The CFS Number - 
Foreign Key into the 
cadcfsdb2 table 

146 cadperdb2 cadperdb2 stamp_cre Date and time the person 
info was attached to a 
CFS 

147 cadperdb2 cadperdb2 tim_cre Time the person 
information was 
attached to a CFS 

148 cadperdb2 cadperdb2 dow_cre Day of the week the 
person information was 
attached to a CFS 

149 cadperdb2 cadperdb2 arm_dan Person armed and 
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Bue VED Cad Table Name Table DBTableName DBFieldName Description 
# element 
dangerous? 
150 1.4a cadperdb2 cadperdb2 name Name of person (Last, 
Owner's First, Middle) 
Name, 1.5 
Occupant's 
Name 
151 cadperdb2 cadperdb2 ssn Person's Social Security 
Number 
152 1.4a cadperdb2 cadperdb2 SeX Person's sex 
Owner's 
Gender, 
1.5 
Occupant's 
Gender 
153 cadperdb2 cadperdb2 dob_str Person's Date of Birth - 
String Format 
154 cadperdb2 cadperdb2 dob Person's Date of Birth - 
Date Format 
155 cadperdb2 cadperdb2 race Person's Race 
156 cadperdb2 cadperdb2 age_str Person's Age 
157 1.4a cadperdb2 cadperdb2 age Person's Age Integer 
Owner's 
Age, 1.5 
Occupant's 
Age 
158 cadperdb2 cadperdb2 ageunit Not filled 
159 cadperdb2 cadperdb2 ageyear Not filled 
160 cadperdb2 cadperdb2 height_str Person's Height - String 
Format 
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Bue VED Cad Table Name Table DBTableName DBFieldName Description 
# element 

161 cadperdb2 cadperdb2 height Person's Height - Integer 

162 cadperdb2 cadperdb2 weight_str Person's Weight - String 
Format 

163 cadperdb2 cadperdb2 weight Person's Weight - Integer 

164 cadperdb2 cadperdb2 hair Person's hair color 

165 cadperdb2 cadperdb2 eyes Person's eye color 

166 cadperdb2 cadperdb2 complx Person's complexion 

167 cadperdb2 cadperdb2 drlic Operator License 
Number 

168 cadperdb2 cadperdb2 per_state Person's state 

169 cadperdb2 cadperdb2 per_address Person's address 

170 cadperdb2 cadperdb2 per_phone Person's phone number 

171 cadperdb2 cadperdb2 per_stored Indicates if the person 
record was stored in the 
GenInfo database 

172 cadperdb2 cadperdb2 per_gid type General Information 
database Type (BOLO, 
Missing Person, Suspect 

173 cadperdb2 cadperdb2 Isw What the person was last 
seen wearing 

174 cadperdb2 cadperdb2 per_misc Miscellaneous 
information about the 
person 

175 cadperdb2 cadperdb2 per_reqby Person Who Requested 
the Query 

176 cadperdb2 cadperdb2 cfs_numbr The CFS Number 
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177 cadperdb2 cadperdb2 pxfield1 Extra fields - Not Filled 
178 cadperdb2 cadperdb2 pxfield2 Extra fields - Not Filled 
179 cadperdb2 cadperdb2 pxfield3 Extra fields - Not Filled 
180 cadperdb2 cadperdb2 pxfield4 Extra fields - Not Filled 
181 
182 CadReadinessTable CadReadinessLevel CadReadinessLevel SectorlD 
183 CadReadinessLevel CadReadinessLevel EnteredDate 
184 CadReadinessLevel CadReadinessLevel ReadinessLevel 
185 CadReadinessLevel CadReadinessLevel UserName 
186 
187 CadRosterTable cadrosdb2 cadrosdb2 ros_arch 
188 cadrosdb2 cadrosdb2 ros_number 
189 cadrosdb2 cadrosdb2 ros_beg stmp 
190 cadrosdb2 cadrosdb2 ros_end_stmp 
191 cadrosdb2 cadrosdb2 ros_user 
192 cadrosdb2 cadrosdb2 ros_host 
193 cadrosdb2 cadrosdb2 ros_type 
194 
195 CadSectorsTable CadSectors CadSectors SectorlD 
196 CadSectors CadSectors SectorName 
197 CadSectors CadSectors Region|ID 
198 
199 CadSubUnitTable cadsubdb2 cadsubdb2 sub_arch 
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poe VED Cad Table Name Table DBTableName DBFieldName Description 
# element 

200 cadsubdb2 cadsubdb2 sub_num 

201 cadsubdb2 cadsubdb2 unt_number Unit identifier 

202 cadsubdb2 cadsubdb2 sub_unit_id Subunit name or 
identifier 

203 cadsubdb2 cadsubdb2 sub_unit_desc Subunit description or 
attributes 

204 cadsubdb2 cadsubdb2 cfs_numbr 

205 

206 CadUnitTrakTable cadtrkdb2 cadtrkdb2 trk_arch Always "0015" 

207 cadtrkdb2 cadtrkdb2 trk_number A sequence number 
generated by cad2rms(d) 

208 cadtrkdb2 cadtrkdb2 unt_stmp_chg Date and time the unit 
changed status 

209 cadtrkdb2 cadtrkdb2 unt_trk_stat Status of the unit 

210 cadtrkdb2 cadtrkdb2 unt_number Unit Identifier 

211 cadtrkdb2 cadtrkdb2 Inkunt Linked Unit Number 

212 cadtrkdb2 cadtrkdb2 dbl_number Unit identifier and Linked 
Unit Number separated 
by "/" (slash) 

213 cadtrkdb2 cadtrkdb2 untcfsNumber CFS Number to which the 
unit was attached 

214 cadtrkdb2 cadtrkdb2 zone Zone to which the unit 
was attached 

215 cadtrkdb2 cadtrkdb2 incCode Incident Code of the CFS 
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to which the unit was 
attached 


Bue VED Cad Table Name Table DBTableName DBFieldName Description 
# element 

216 cadtrkdb2 cadtrkdb2 location Incident Location of the 
CFS to which the unit 
was attached 

217 cadtrkdb2 cadtrkdb2 message Any messages attached 
to the unit 

218 cadtrkdb2 cadtrkdb2 trk_type Unit = 5; SubUnit = 23 

219 cadtrkdb2 cadtrkdb2 UserName Unit identified if change 
made via switcher else 
User making unit change 

220 cadtrkdb2 cadtrkdb2 Location_x Unit's geocode location 
when Address changes 

221 cadtrkdb2 cadtrkdb2 Location_y Unit's geocode location 
when Address changes 

222 cadtrkdb2 cadtrkdb2 Latitude Unit's location when 
Address changes 

223 cadtrkdb2 cadtrkdb2 Longitude Unit's location when 
Address changes 

224 cadtrkdb2 cadtrkdb2 Mileage Not filled 

225 cadtrkdb2 cadtrkdb2 bndxfield County as translated by 
ZoneCounty.dat; enabled 
with "(cad2rmsqd) fill 
county in cadtrkdb2 table 
= True" 

226 cadtrkdb2 cadtrkdb2 Boundary Not filled 

227 cadtrkdb2 cadtrkdb2 EventType The reason for updating 
an AVL enabled unit 

228 cadtrkdb2 cadtrkdb2 UXField1 Extra fields - Not Filled 

229 cadtrkdb2 cadtrkdb2 UXField2 Extra fields - Not Filled 
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sh Nee Cad Table Name Table DBTableName DBFieldName Description 

230 

231 CadUnitTable caduntdb2 caduntdb2 unt_arch Always "0017" 

232 caduntdb2 caduntdb2 unt_nmbr The CFS Number - 
Foreign Key into the 
cadcfsdb2 table 

233 caduntdb2 caduntdb2 un_nmbr Unit identifier 

234 caduntdb2 caduntdb2 u_agency Agency of unit 

235 caduntdb2 caduntdb2 new_stat Status of a unit 

236 caduntdb2 caduntdb2 stamp_change Date and time the unit 
changed status 

237 caduntdb2 caduntdb2 tim_change Time a unit changed 
status 

238 caduntdb2 caduntdb2 dow_change Day of the week a unit 
changed status 

239 caduntdb2 caduntdb2 zone Zone 

240 caduntdb2 caduntdb2 cfs_numbr The CFS Number 

241 caduntdb2 caduntdb2 Uxfield Extra fields - Not Filled 

242 

243 CadUnitTimeTable CadUntTime cadunttime u_tm_nmbr 

244 CadUntTime cadunttime u_rcvd2enrt 

245 CadUntTime cadunttime u_sent2enrt 

246 CadUntTime cadunttime u_disp2enrt 

247 CadUntTime cadunttime u_rcvd2onsc 

248 CadUntTime cadunttime u_sent2onsc 

249 CadUntTime cadunttime u_disp2onsc 
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Bue VED Cad Table Name Table DBTableName DBFieldName Description 
# element 

250 CadUntTime cadunttime u_enrt2onsc 

251 

252 CadVehicleTable cadvehdb2 cadvehdb2 veh_arch Always "0005" 

253 cadvehdb2 cadvehdb2 veh_nmbr The CFS Number - 
Foreign Key into the 
cadcfsdb2 table 

254 cadvehdb2 cadvehdb2 status Vehicle's status 

255 cadvehdb2 cadvehdb2 stmp_cre Date and time the 
vehicle information was 
attached to a CFS 

256 cadvehdb2 cadvehdb2 time_cre Time the vehicle 
information was 
attached to a CFS 

257 cadvehdb2 cadvehdb2 dow_time Day of the week the 
vehicle was attached to a 
CFS 

258 cadvehdb2 cadvehdb2 arm_dang Is the person operating 
the vehicle armed and 
dangerous? 

259 cadvehdb2 cadvehdb2 year_str Vehicle's year 

260 1.4a Year cadvehdb2 cadvehdb2 year 

261 1.4a cadvehdb2 cadvehdb2 license Vehicle's license 

License 
Plate 
262 1.4a cadvehdb2 cadvehdb2 state Vehicle's license state 
Owner's 
State and 
Province 
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# element 
263 1.4a Make cadvehdb2 cadvehdb2 make Vehicle's make 
264 14a cadvehdb2 cadvehdb2 model Vehicle's model 
Model 

265 1.4a Color cadvehdb2 cadvehdb2 color Vehicle's color 

266 1.4a VIN cadvehdb2 cadvehdb2 vin Vehicle's Identification 
Number 

267 cadvehdb2 cadvehdb2 type License Type 

268 cadvehdb2 cadvehdb2 veh_stored Vehicle Stored 

269 cadvehdb2 cadvehdb2 veh_gid_type General Info Database 
record type; configurable 
in GIDBTypes.dat (e.g. 
BOLO, Suspect) 

270 1.4a Body cadvehdb2 cadvehdb2 VehType Vehicle Type 

Type 

271 cadvehdb2 cadvehdb2 veh_reqby Person Who Requested 
Query 

272 cadvehdb2 cadvehdb2 veh_licyr Vehicle License Year 

273 cadvehdb2 cadvehdb2 cfs_numbr The CFS Number 

274 cadvehdb2 cadvehdb2 vxfield1 Extra fields - Not Filled 

275 cadvehdb2 cadvehdb2 veh_misc Miscellaneous 
information associated 
with the vehicle 

276 cadvehdb2 cadvehdb2 TextInfo Large miscellaneous text 
field 

277 

278 CadWeatherTable CadWeatherManagemen | CadWeatherManagemen | WeatherZonelD 


t 
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Li VED 
hes : Cad Table Name Table DBTableName DBFieldName Description 
# element 
279 CadWeatherManagemen | CadWeatherManagemen | CategoryDay 
t t 
280 CadWeatherManagemen | CadWeatherManagemen | TransportDirection 
t t 
281 CadWeatherManagemen | CadWeatherManagemen | TransportSpeed 
t t 
282 CadWeatherManagemen | CadWeatherManagemen | SurfaceDirection 
t t 
283 CadWeatherManagemen | CadWeatherManagemen | SurfaceSpeed 
t t 
284 CadWeatherManagemen | CadWeatherManagemen | NightDispersion 
t t 
285 CadWeatherManagemen | CadWeatherManagemen | UserName 
t t 
286 CadWeatherManagemen | CadWeatherManagemen | EnteredDate 
t t 
287 
288 CadWeatherZonesTable CadWeatherZones CadWeatherZones WeatherZonelD 
289 CadWeatherZones CadWeatherZones WeatherZoneName 
290 CadWeatherZones CadWeatherZones Region|ID 
291 
292 CadCrossReferenceTable cadxrefdb2 cadxrefdb2 cfs_numbr The CFS Number - 
Foreign Key into the 
cadcfsdb2 table 
293 cadxrefdb2 cadxrefdb2 xref_cfs CFS Number of cross- 
refed cfs 
294 cadxrefdb2 cadxrefdb2 origin Not filled 
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295 cadxrefdb2 cadxrefdb2 typeofxref Type of Cross Reference 

296 

297 CadCFSTableForTimeDifference CFS cadcfsdb2 cfs_arch Always '0001' 

298 CFS cadcfsdb2 cfs_numbr The call for service 
number of the incident. 
Part 1 of 1 part primary 
key. 

299 CFS cadcfsdb2 priority The priority of the CFS. 

300 CFS cadcfsdb2 inc_code The code for the 
incident. 

301 CFS cadcfsdb2 address The location of the 
incident. 

302 CFS cadcfsdb2 landmark The landmark name 
associated with the 
address. 

303 CFS cadcfsdb2 apt_number The apartment 
associated with the 
incident address. 

304 CFS cadcfsdb2 city The city associated with 
the incident address. 

305 CFS cadcfsdb2 address _x the X coordinate of the 
Person's address 

306 CFS cadcfsdb2 address_y the Y coordinate of the 
Person's address 

307 CFS cadcfsdb2 zonel The zones in which the 
incident occurred. 

308 CFS cadcfsdb2 zone2 The zones in which the 


incident occurred. 
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309 CFS cadcfsdb2 addrtype The address type. 

310 CFS cadcfsdb2 onbound Boundary Information 

311 CFS cadcfsdb2 bound1 Not Filled 

312 CFS cadcfsdb2 bound2 Not Filled 

313 CFS cadcfsdb2 bound3 Not Filled 

314 CFS cadcfsdb2 bound4 Not Filled 

315 CFS cadcfsdb2 alarm_no Indicates whether the 
person had a security 
alarm. 

316 CFS cadcfsdb2 offr_cntct Indicates whether the 
complainant requested 
to speak with an officer. 

317 CFS cadcfsdb2 line_number The phone line on which 
the call was received. 

318 CFS cadcfsdb2 how_recd The description of the 
source of the dispatch 
initiating the CFS. 

319 CFS cadcfsdb2 in_progres Indicates whether the 
incident was in progress 
at the time of the CFS. 

320 CFS cadcfsdb2 call_taker The login name of the 
call taker who entered 
the CFS. 

321 CFS cadcfsdb2 complainan The name of the person 
placing the CFS. 

322 CFS cadcfsdb2 curr_phone The phone number from 
which the complainant 
called. 
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aes See Cad Table Name Table DBTableName DBFieldName Description 
# element 

323 CFS cadcfsdb2 comp_addre The complainant's home 
address. 

324 CFS cadcfsdb2 res_phone The complainant's home 
telephone number. 

325 CFS cadcfsdb2 weapon Indicates if a weapon 
was involved in the CFS. 

326 CFS cadcfsdb2 dispatcher The name of the 
dispatcher. 

327 CFS cadcfsdb2 priunit The reporting officer for 
a generated Records 
report. 

328 CFS cadcfsdb2 finaldisp The Final Disposition of 
the CFS. 

329 CFS cadcfsdb2 building The building number 
associated with the 
address. 

330 CFS cadcfsdb2 busname The business name 
associated with the 
address. 

331 CFS cadcfsdb2 stmp_rcvd The date and time that 
the call occurred. 

332 CFS cadcfsdb2 time_rcvd The time the call 
occurred. 

333 CFS cadcfsdb2 dow_rcvd The day of the week on 
which the incident 
occurred. 

334 CFS cadcfsdb2 stmp_sent The date and time that 
the units were sent to 
respond. 
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335 CFS cadcfsdb2 time_sent The time the units were 
sent to the CFS. 

336 CFS cadcfsdb2 dow_sent The day of the week of 
the time_sent 

337 CFS cadcfsdb2 stmp_disp The date and time the 
CFS was dispatched. 

338 CFS cadcfsdb2 time_disp The time the CFS was 
dispatched. 

339 CFS cadcfsdb2 dow_disp The day of the week of 
the time_disp. 

340 CFS cadcfsdb2 stmp_cenrt The date and time the 
CFS went EnRoute. 

341 CFS cadcfsdb2 time_cenrt The time the CFS went 
EnRoute. 

342 CFS cadcfsdb2 dow_cenrt The day of the week the 
CFS went EnRoute. 

343 CFS cadcfsdb2 stmp_consc The date and time the 
CFS went OnScene. 

344 CFS cadcfsdb2 time_consc The time the CFS went 
Onscene. 

345 CFS cadcfsdb2 dow_consc The day of the week the 
CFS wend OnScene. 

346 CFS cadcfsdb2 stmp_cmpl The date the CFS was 
completed. 

347 CFS cadcfsdb2 time_cmpl The time the CFS was 
completed. 

348 CFS cadcfsdb2 dow_cmpl The day of the week the 
CFS was completed. 
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349 CFS cadcfsdb2 stamp_att_any Always '9999-12-31- 
24.00.00.000000' 

350 CFS cadcfsdb2 tim_att_any Always '24.00.00' 

351 CFS cadcfsdb2 dow_att_any Always " (blank) 

352 CFS cadcfsdb2 duration The difference between 
the time completed and 
the time received (in 
seconds) 

353 CFS cadcfsdb2 routetime The difference between 
the time sent and the 
time received (in 
seconds) 

354 CFS cadcfsdb2 disptime The time units were 
dispatched. 

355 CFS cadcfsdb2 LinkIndex The link index number. 

356 CFS cadcfsdb2 agency Description of the agency 
the event occurred in 
(not filled by default) 

357 CFS cadcfsdb2 ZONE Used for Print Report 

358 CFS cadcfsdb2 INC_DESCRIPT Used for Print Report 

359 CFS cadcfsdb2 XFIELD4 Used for Print Report 

360 CFS cadcfsdb2 cancelled Used for Print Report 

361 CFS cadcfsdb2 CENRTTIME Used for Print Report 

362 CFS cadcfsdb2 COMPLETIONTIME Used for Print Report 

363 CFS cadcfsdb2 CONSCTIME Used for Print Report 

364 CFS cadcfsdb2 DISTRICT Used for Print Report 
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365 CFS cadcfsdb2 DOW_ARCH Used for Print Report 

366 CFS cadcfsdb2 FLOOR Used for Print Report 

367 CFS cadcfsdb2 TimeReceived Used for Print Report 

368 CFS cadcfsdb2 MAP_PAGE Used for Print Report 

369 CFS cadcfsdb2 MISSING_TIMES Used for Print Report 

370 CFS cadcfsdb2 STATION Used for Print Report 

371 CFS cadcfsdb2 STMP_ARCH Used for Print Report 

372 CFS cadcfsdb2 TIME_ARCH Used for Print Report 

373 CFS cadcfsdb2 XFIELD1 Used for Print Report 

374 CFS cadcfsdb2 DispatchTime Used for Print Report 

375 CFS cadcfsdb2 TimeSent Used for Print Report 

376 CFS cadcfsdb2 XFIELD3 Used for Print Report 

377 CFS cadcfsdb2 XFIELD2 Used for Print Report 

378 CFS cadcfsdb2 IncLatitude 

379 CFS cadcfsdb2 IncLongitude 

380 CFS cadcfsdb2 BoundaryID 

381 CFS cadcfsdb2 RcvdDate The date and time that 
the call occurred. 

382 CFS cadcfsdb2 Time_Strt 

383 CFS cadcfsdb2 Comp_x Complainant Address X 
coordinate 

384 CFS cadcfsdb2 Comp_y Complainant Address Y 
coordinate 

385 CFS cadcfsdb2 CompLongitude Complainant Address 

Data Book 135 


ane Nee Cad Table Name Table DBTableName DBFieldName Description 
Longitude 

386 CFS cadcfsdb2 Dow_Strt SCFC Burn start day of 
the week 

387 CFS cadcfsdb2 platoon Not filled 

388 CFS cadcfsdb2 Stmp_Strt SCFC Burn start time 

389 CFS cadcfsdb2 TimeAttAny Not filled 

390 CFS cadcfsdb2 XField5 Used for Print Report 

391 CFS cadcfsdb2 XField6 Used for Print Report 

392 CFS cadcfsdb2 XField7 Used for Print Report 

393 CFS cadcfsdb2 XField10 Used for Print Report 

394 CFS cadcfsdb2 XField11 Used for Print Report 

395 CFS cadcfsdb2 XField12 Used for Print Report 

396 CFS cadcfsdb2 XField8 Used for Print Report 

397 CFS cadcfsdb2 XField13 Used for Print Report 

398 CFS cadcfsdb2 XField9 Used for Print Report 

399 

400 CFSBoundary cadbnddb2 bnd_nmbr The CFS number this 
boundary record is 
associated with. 

401 CFSBoundary cadbnddb2 bind_id The boundary 
description. 

402 CFSBoundary cadbnddb2 resp_level The response level. 

403 CFSBoundary cadbnddb2 resp_code The response code. 

404 CFSBoundary cadbnddb2 agency Agency associated with 
this boundary 
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405 

406 CFSCadTrk cadtrkdb2 trk_arch 

407 CFSCadTrk cadtrkdb2 trk_number 

408 CFSCadTrk cadtrkdb2 unt_stmp_chg 

409 CFSCadTrk cadtrkdb2 unt_trk_stat 

410 CFSCadTrk cadtrkdb2 unt_number 

411 CFSCadTrk cadtrkdb2 Inkunt 

412 CFSCadTrk cadtrkdb2 dbl_number 

413 CFSCadTrk cadtrkdb2 untcfsNumber 

414 CFSCadTrk cadtrkdb2 zone 

415 CFSCadTrk cadtrkdb2 incCode 

416 CFSCadTrk cadtrkdb2 location 

417 CFSCadTrk cadtrkdb2 message 

418 CFSCadTrk cadtrkdb2 trk_type 

419 CFSCadTrk cadtrkdb2 UserName 

420 CFSCadTrk cadtrkdb2 Location_x 

421 CFSCadTrk cadtrkdb2 Location_y 

422 CFSCadTrk cadtrkdb2 Latitude 

423 CFSCadTrk cadtrkdb2 Longitude 

424 CFSCadTrk cadtrkdb2 Mileage 

425 

426 CadCFSCommentsTable CFSComments cadcomdb2 com_arch Always '0002' 

427 CFSComments cadcomdb2 com_numbr The CFS number. 
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# element 
428 CFSComments cadcomdb2 sequence Not filled 
429 CFSComments cadcomdb2 stmp_creat The date and time the 
comment was created. 
430 CFSComments cadcomdb2 time_creat The time the comment 
was created. 
431 CFSComments cadcomdb2 dow_creat The day of the week the 
comment was created. 
432 CFSComments cadcomdb2 com_name The name of the user 
who created this 
comment. 
433 1.1 CFSComments cadcomdb2 com_ment The text of the comment. 
Incident ID 
#,1.2 
Incident 
Date/Time, 
LTD 
Confidence 
, Device 
Event 
Type, 1.4b 
Ignition 
State, 
Heading, 
Orientatio 
n, Fire, 
Multiple 
Impacts, 
Deployed, 
1.5 #of 
occupants, 
conscious, 
breathing, 
speaking, 
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moving 
arm, 
moving 
leg, 
external 
bleeding, 
entrapped, 
ejected, 
seat 
position, 
restraint 
type, 
injury 
patterns 
434 
435 CadCFSDispatchTable CFSDispatch caduntdb2 unt_arch Always '0017'. 
436 CFSDispatch caduntdb2 unt_nmbr The CFS number of this 
unit record. 
437 CFSDispatch caduntdb2 un_nmbr The unit number sent. 
438 CFSDispatch caduntdb2 u_agency The ID number of the 
agency referenced. 
439 CFSDispatch caduntdb2 new_stat The status of the unit. 
440 CFSDispatch caduntdb2 stamp_change The date and time the 
unit changed status. 
441 CFSDispatch caduntdb2 tim_change The time the unit 
changed status 
442 CFSDispatch caduntdb2 dow_change The day of the week the 
unit changed status. 
443 
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444 CadCFSIncidentTable CFSIncident caddrndb2 drn_arch Always '0004' 

445 CFSIncident caddrndb2 drn_nmbr The CFS number. 

446 CFSIncident caddrndb2 d_agency The ID number of the 
agency referenced. 

447 CFSIncident caddrndb2 dr_nmbr The DR number. 

448 CFSIncident caddrndb2 stmp_att_drn Always '9999-12-31- 
24.00.00.000000' 

449 CFSIncident caddrndb2 stmp_onsc_drn Always '9999-12-31- 
24.00.00.000000' 

450 CFSIncident caddrndb2 stmp_ofsc_drn Always '9999-12-31- 
24.00.00.000000' 

451 CFSIncident caddrndb2 resptime Always -999 

452 CFSIncident caddrndb2 dr_duration Always -999 

453 CFSincident caddrndb2 unit 

454 

455 CadCfsPersonTable CFSPerson cadperdb2 pxfield3 

456 CFSPerson cadperdb2 per_reqby 

457 CFSPerson cadperdb2 per_arch Always '0006' 

458 CFSPerson cadperdb2 per_nmbr The CFS number. 

459 CFSPerson cadperdb2 stamp_cre The date and time the 
person record was 
created. 

460 CFSPerson cadperdb2 tim_cre The time the person 
record was created. 

461 CFSPerson cadperdb2 dow_cre The day of the week the 
person record was 
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created. 

462 CFSPerson cadperdb2 arm_dan Indicates whether the 
individual was armed and 
dangerous. 

463 CFSPerson cadperdb2 name The name of the 
individual. 

464 CFSPerson cadperdb2 ssn The civilian's social 
security number. 

465 CFSPerson cadperdb2 SeX The gender of the 
civilian. 

466 CFSPerson cadperdb2 dob The civilian's date of 
birth. 

467 CFSPerson cadperdb2 race The race of the civilian. 

468 CFSPerson cadperdb2 age The officer's age at the 
incident event. 

469 CFSPerson cadperdb2 ageunit Not filled. 

470 CFSPerson cadperdb2 ageyear Not filled. 

471 CFSPerson cadperdb2 height The individual's height. 

472 CFSPerson cadperdb2 weight The individual's weight. 

473 CFSPerson cadperdb2 hair The individual's hair 
color. 

474 CFSPerson cadperdb2 eyes The individual's eye 
color. 

475 CFSPerson cadperdb2 complx The individual's skin 
complexion condition. 

476 CFSPerson cadperdb2 drlic The civilian's driver 
license number. 
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477 CFSPerson cadperdb2 per_state The state the individual is 
from. 

478 CFSPerson cadperdb2 per_address The individual's address. 

479 CFSPerson cadperdb2 per_phone The individual's phone 
number. 

480 CFSPerson cadperdb2 per_stored Indicates if the person 
record was stored to the 
Genlnfo database. 

481 CFSPerson cadperdb2 per_gid_type The type of record in the 
GenInfo database (if 
stored). 

482 CFSPerson cadperdb2 Isw The description of what 
the individual was last 
seen wearing. 

483 CFSPerson cadperdb2 per_misc Any misc. comments 
concerning the 
individual. 

484 

485 CadCFSSubUnitTable CFSSubUnit cadsubdb2 sub_arch 

486 CFSSubUnit cadsubdb2 sub_num 

487 CFSSubUnit cadsubdb2 unt_number 

488 CFSSubUnit cadsubdb2 sub_unit_id 

489 CFSSubUnit cadsubdb2 sub_unit_desc 

490 CFSSubUnit cadsubdb2 cfs_numbr 

491 

492 CadCFSVehicleTable CFSVehicle cadvehdb2 veh_arch Always '0005' 
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493 CFSVehicle cadvehdb2 veh_nmbr The CFS number. 

494 CFSVehicle cadvehdb2 status 

495 CFSVehicle cadvehdb2 stmp_cre The date and time this 
vehicle record was 
created. 

496 CFSVehicle cadvehdb2 time_cre The time this vehicle 
record was created. 

497 CFSVehicle cadvehdb2 dow_time The day of the week this 
vehicle record was 
created. 

498 CFSVehicle cadvehdb2 arm_dang The armed and 
dangerous value for this 
vehicle. 

499 CFSVehicle cadvehdb2 year The year of the vehicle. 

500 CFSVehicle cadvehdb2 license The license number of 
the equipment. 

501 CFSVehicle cadvehdb2 state The state, which the 
vehicle is licensed under. 

502 CFSVehicle cadvehdb2 make The make of the 
equipment. 

503 CFSVehicle cadvehdb2 model The model of the 
equipment. 

504 CFSVehicle cadvehdb2 color The color of the vehicle. 

505 CFSVehicle cadvehdb2 vin The VIN number of the 
vehicle. 

506 CFSVehicle cadvehdb2 type The vehicle's 
involvement in the CFS. 
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507 CFSVehicle cadvehdb2 veh_stored Indicates if the vehicle 
record was stored in the 
Genlnfo database. 

508 CFSVehicle cadvehdb2 veh_gid_type The type of record in the 
GenInfo database (if 
stored). 

509 CFSVehicle cadvehdb2 veh_misc A description of the 
diagram. 

510 CFSVehicle cadvehdb2 veh_licyr The year that the 
vehicle's license expires. 
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Line # | VEDS element Element Code | OPHI-PCR Data Element X = Data 
(Red and Elements to be 
Yellow are Tested for 
NEMSIS Compliance 
elements (Red = Required 
collected by National Data 
the state) Elements) 

2 DO1 01 EMS Agency Number X 

3 1.1 Provider Name DO1 02 EMS Agency Name 

4 DO1_03 EMS Agency State X 

5 DO1_04 EMS Agency County X 

6 DO1_05 Primary Type of Service 

7 DO1 06 Other Types of Service 

8 DO1_07 Level of Service X 

9 DO1 08 Organizational Type X 

10 DO1_09 Organization Status X 

11 DO1_10 Statistical Year X 

12 DO1 11 Other Agencies In Area 

13 DO1 12 Total Service Size Area X 

14 DO1 13 Total Service Area Population X 

15 DO1 14 911 Call Volume per Year X 

16 DO1 15 EMS Dispatch Volume per Year X 

17 DO1_16 EMS Transport Volume per Year X 

18 DO1_17 EMS Patient Contact Volume per Year X 

19 DO1 18 EMS Billable Calls per Year 

20 DO1_19 EMS Agency Time Zone X 

21 DO1_20 EMS Agency Daylight Savings Time Use 

22 DO1 21 National Provider Identifier X 

23 DO2_01 Agency Contact Last Name 

24 DO2_02 Agency Contact Middle Name/Initial 

25 DO2_03 Agency Contact First Name 

26 DO2_04 Agency Contact Address 

27 DO2_05 Agency Contact City 

28 DO2_06 Agency Contact State 

29 DO2_07 Agency Contact Zip Code X 
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30 1.1 Call Back # DO2_08 Agency Contact Telephone Number 

31 DO2_09 Agency Contact Fax Number 

32 DO2_10 Agency Contact Email Address 

33 DO2_11 Agency Contact Web Address 

34 DO3_01 Agency Medical Director Last Name 

35 DO3_02 Agency Medical Director Middle Name/Initial 

36 DO3_03 Agency Medical Director First Name 

37 DO3_04 Agency Medical Director Address 

38 DO3_05 Agency Medical Director City 

39 DO3_06 Agency Medical Director State 

40 DO3_07 Agency Medical Director Zip Code 

41 DO3_08 Agency Medical Director Telephone Number 

42 DO3_09 Agency Medical Director Fax Number 

43 DO3_10 Agency Medical Director's Medical Specialty 

44 DO3_11 Agency Medical Director Email Address 

45 DO4_01 State Certification Licensure Levels 

46 DO4_02 EMS Unit Call Sign 

47 DO04_03 Zones 

48 DO4_05 Personnel Level Permitted to Use the Procedure 

49 DO4_06 Medications Given 

50 DO4_07 Personnel Level Permitted to Use the Medication 

51 DO4_08 Protocol 

52 DO4_09 Personnel Level Permitted to Use the Protocol 

53 DO4_10 Billing Status 

54 DO4_11 Hospitals Served 

55 DO4_12 Hospital Facility Number 

56 DO4_13 Other Destinations 

57 DO4 14 Destination Facility Number 

58 DO4_15 Destination Type 
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59 DO4_16 Insurance Companies Used 

60 DO4_17 EMD Vendor 

61 DO5_01 Station Name 

62 DOS _02 Station Number 

63 DO5_03 Station Zone 

64 DO5_04 Station GPS 

65 DOS_05 Station Address 

66 DOS_06 Station City 

67 DO5_07 Station State 

68 DO5_08 Station Zip 

69 DOS_09 Station Telephone Number 

70 DO6_01 Unit/Vehicle Number 

71 DO6_03 Vehicle Type 

72 DO6_04 State Certification/Licensure Levels 

73 DO6_05 Number Of Each Personnel Level on the Vehicle Crew 

74 DO6_06 Vehicle Initial Cost 

75 DO6_07 Vehicle Model Year 

76 DO6_08 Year Miles/Hours Accrued 

77 DO6_09 Annual Vehicle Hours 

78 DO6_10 Annual Vehicle Miles 

79 DO7_01 Personnel's Agency ID Number 

80 DO7_02 State/Licensure ID Number 

81 DO7_03 Personnel's Employment Status 

82 DO7_04 Employment Status Date 

83 DO7_05 Personnel's Level of Certification/Licensure for Agency 

84 DO7_06 Date of Personnel's Certification or Licensure for Agency 

85 DO8_01 EMS Personnel's Last Name 

86 DO8_ 02 EMS Personnel's Middle Name/Initial 

87 DO8_03 EMS Personnel's First Name 
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88 DO8_04 EMS Personnel's Mailing Address 

89 DO8_05 EMS Personnel's City of Residence 

90 DO8_06 EMS Personnel's State 

91 DO8_07 EMS Personnel's Zip Code 

92 DO8_08 EMS Personnel's Work Telephone 

93 DO8_09 EMS Personnel's Home Telephone 

94 DO8_10 EMS Personnel's Email Address 

95 DO8_11 EMS Personnel's Date Of Birth 

96 DO8_ 12 EMS Personnel's Gender 

97 DO8_13 EMS Personnel's Race 

98 DO8_ 14 EMS Personnel's Ethnicity 

99 DO8_15 State EMS Certification Licensure Level 

100 DO8_16 National Registry Credentialed 

101 DO8_17 State EMS Current Certification Date 

102 DO8_18 Initial State Certification Date 

103 DO8_19 Total Length of Service 

104 DO8_20 Date Length of Service Documented 

105 DOS 01 Device Serial Number 

106 DOI 02 Device Name or ID 

107 DOS 03 Device Manufacturer 

108 DOS 04 Model Number 

109 DOS _05 Device Purchase Date 

110 E01 01 Patient Care Report Number X 

111 E01 02 Software Creator X 

112 E01 _03 Software Name X 

113 E01 04 Software Version X 

114 EO2_01 EMS Agency Number X 

115 1.1 Incident # EO2_02 Incident Number 

116 E02_03 EMS Unit (Vehicle) Response Number 
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117 EO2_04 Type of Service Requested X 

118 E02_05 Primary Role of the Unit X 

119 EO2_06 Type of Dispatch Delay X 

120 EO2_07 Type of Response Delay X 

121 E02_08 Type of Scene Delay X 

122 E02_09 Type of Transport Delay X 

123 EO2_10 Type of Turn-Around Delay X 

124 E£02_11 EMS Unit/Vehicle Number 

125 E02 12 EMS Unit Call Sign (Radio Number) X 

126 EO2_13 Vehicle Dispatch Location 

127 EO2_ 14 Vehicle Dispatch Zone 

128 EO2_15 Vehicle Dispatch GPS Location 

129 EO2_16 Beginning Odometer Reading of Responding Vehicle 

130 EO2_17 On-Scene Odometer Reading of Responding Vehicle 

131 EO2_18 Patient Destination Odometer Reading of Responding Vehicle 

132 E02_19 Ending Odometer Reading of Responding Vehicle 

133 EO2_20 Response Mode to Scene X 

134 E03 01 Complaint Reported by Dispatch X 

135 E03 02 EMD Performed X 

136 E03 _03 EMD Card Number 

137 E04 01 Crew Member ID 

138 E04 _02 Crew Member Role 

139 E04_03 Crew Member Level 

140 1.2 Event Time E05 01 Incident or Onset Date/Time 

141 E05 02 PSAP Call Date/Time X 

142 E05 _03 Dispatch Notified Date/Time 

143 1.2 Received EOS 04 Unit Notified by Dispatch Date/Time X 

Date/Time of 
Incident 
144 E05 _05 Unit En Route Date/Time X 
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145 EO5_06 Unit Arrived on Scene Date/Time X 
146 E05 _07 Arrived at Patient Date/Time X 
147 E05 08 Transfer of Patient Care Date/Time 
148 E05 _09 Unit Left Scene Date/Time X 
149 EO5_10 Patient Arrived at Destination Date/Time X 
150 E05 11 Unit Back in Service Date/Time X 
151 E05 12 Unit Cancelled Date/Time 
152 E05 _13 Unit Back at Home Location Date/Time X 
153 1.5 Occupant's E06 01 Last Name 
Name 
154 1.5 Occupant's E06 _02 First Name 
Name 
155 1.5 Occupant's E06_03 Middle Initial/Name 
Name 
156 E06 04 Patient's Home Address 
157 E06_05 Patient's Home City 
158 E06 _06 Patient's Home County 
159 E06_07 Patient's Home State 
160 E06_08 Patient's Home Zip Code X 
161 E06_09 Patient’s Home Country 
162 1.6 Subscriber E06 _10 Social Security Number 
Government IDs 
163 1.5 Occupant's E06 11 Gender X 
Gender 
164 E06_12 Race X 
165 E06_13 Ethnicity X 
166 1.5 Occupant's Age E06 14 Age X 
167 1.5 Occupant's Age E06 15 Age Units X 
168 E06 16 Date of Birth 
169 E06 _17 Primary or Home Telephone Number 
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the state) Elements) 

170 1.6 Driver License E06 18 State Issuing Driver's License 

State 

171 1.6 Driver License # | E06_19 Driver's License Number 

172 EO7_01 Primary Method of Payment X 

173 EO7_02 Certificate of Medical Necessity 

174 1.6 Insurance E07_03 Insurance Company ID/Name 

Provider Name 

175 EO7_04 Insurance Company Billing Priority 

176 EO7_05 Insurance Company Address 

177 EO7_06 Insurance Company City 

178 EO7_07 Insurance Company State 

179 EO7_08 Insurance Company Zip Code 

180 EO7_09 Insurance Group ID/Name 

181 1.6 Policy # EO7_10 Insurance Policy ID Number 

182 EO7_11 Last Name of the Insured 

183 EO7_12 First Name of the Insured 

184 E07_13 Middle Initial/Name of the Insured 

185 EO7_14 Relationship to the Insured 

186 EO7_15 Work-Related 

187 EO7_16 Patient’s Occupational Industry 

188 EO7_17 Patient’s Occupation 

189 EO7_18 Closest Relative/Guardian Last Name 

190 EO7_19 First Name of the Closest Relative/ Guardian 

191 E07_20 Middle Initial/Name of the Closest Relative/ Guardian 

192 EO7_21 Closest Relative/ Guardian Street Address 

193 E0O7_22 Closest Relative/ Guardian City 

194 EO7_23 Closest Relative/ Guardian State 

195 EO7_24 Closest Relative/ Guardian Zip Code 

196 EO7_25 Closest Relative/ Guardian Phone Number 
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Line # | VEDS element Element Code | OPHI-PCR Data Element X = Data 
(Red and Elements to be 
Yellow are Tested for 
NEMSIS Compliance 
elements (Red = Required 
collected by National Data 
the state) Elements) 
197 EO7_26 Closest Relative/ Guardian Relationship 
198 EO7_27 Patient's Employer 
199 EO7_28 Patient's Employer's Address 
200 EO7_29 Patient’s Employer’s City 
201 EO7_30 Patient’s Employer’s State 
202 EO7_31 Patient’s Employer’s Zip Code 
203 EO7_32 Patient's Work Telephone Number 
204 EO7_33 Response Urgency 
205 EO7_34 CMS Service Level X 
206 EO7_35 Condition Code Number X 
207 EO7_36 ICD-9 Code for the Condition Code Number 
208 EO7_37 Condition Code Modifier 
209 E08_01 Other EMS Agencies at Scene 
210 E08 02 Other Services at Scene 
211 E08 03 Estimated Date/Time Initial Responder Arrived on Scene 
212 E08 04 Date/Time Initial Responder Arrived on Scene 
213 1.5 # of Occupants E08_05 Number of Patients at Scene X 
214 E08 06 Mass Casualty Incident X 
215 1.2 Location, E08_07 Incident Location Type X 
Location description 
216 1.2 Location, E08 08 Incident Facility Code 
Location description 
217 1.2 Location, E08_09 Scene Zone Number 
Location description 
218 1.2 Location, E08_10 Scene GPS Location 
Location 
description, 


Latitude, Longitude 
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Line # | VEDS element Element Code | OPHI-PCR Data Element X = Data 
(Red and Elements to be 
Yellow are Tested for 
NEMSIS Compliance 
elements (Red = Required 
collected by National Data 
the state) Elements) 
219 1.2 Location, E08 11 Incident Address 
Location description 
220 1.2 Location, E08 12 Incident City 
Location description 
221 1.2 Location, E08 13 Incident County 
Location description 
222 1.2 Location, E08 14 Incident State 
Location description 
223 1.2 Location, E08 15 Incident ZIP Code X 
Location description 
224 E09 01 Prior Aid X 
225 E09 02 Prior Aid Performed by X 
226 E09 _03 Outcome of the Prior Aid X 
227 E09 04 Possible Injury X 
228 E09 _05 Chief Complaint 
229 E09 06 Duration of Chief Complaint 
230 E09 _07 Time Units of Duration of Chief Complaint 
231 E09 08 Secondary Complaint Narrative 
232 E09 _09 Duration of Secondary Complaint 
233 E09 _10 Time Units of Duration of Secondary Complaint 
234 E09 11 Chief Complaint Anatomic Location X 
235 E09 12 Chief Complaint Organ System X 
236 EO9_ 13 Primary Symptom X 
237 E09 14 Other Associated Symptoms X 
238 E09 15 Providers Primary Impression X 
239 E09 16 Provider’s Secondary Impression X 
240 E10 01 Cause of Injury X 
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Line # | VEDS element Element Code | OPHI-PCR Data Element X = Data 
(Red and Elements to be 
Yellow are Tested for 
NEMSIS Compliance 
elements (Red = Required 
collected by National Data 
the state) Elements) 
241 E10 02 Intent of the Injury 
242 E10 03 Mechanism of Injury 
243 1.4b Fire, 1.5 E10 04 Vehicular Injury Indicators 
Ejected 
244 1.4b Multiple E10 05 Area of the Vehicle impacted by the collision 
Impacts, Rollover 
245 1.5 Seat Position E10 06 Seat Row Location of Patient in Vehicle 
246 E10 07 Position of Patient in the Seat of the Vehicle 
247 1.4b Belt Fastened, E10_ 08 Use of Occupant Safety Equipment 
1.5 Latch Used 
248 1.4b Deployed E10 09 Airbag Deployment 
249 E10 10 Height of Fall 
250 E11 01 Cardiac Arrest X 
251 E11 02 Cardiac Arrest Etiology X 
252 1.5 Breathing E11 03 Resuscitation Attempted X 
253 E11 04 Arrest Witnessed by 
254 E11 05 First Monitored Rhythm of the Patient 
255 E11 06 Any Return of Spontaneous Circulation 
256 E11 07 Neurological Outcome at Hospital Discharge 
257 E11 08 Estimated Time of Arrest Prior to EMS Arrival 
258 E11 09 Date/Time Resuscitation Discontinued 
259 E11 10 Reason CPR Discontinued 
260 E11 11 Cardiac Rhythm on Arrival at Destination 
261 1.5 Entrapped E12 01 Barriers to Patient Care X 
262 E12 02 Sending Facility Medical Record Number 
263 E12_03 Destination Medical Record Number 
264 1.6 Primary Care E12 04 First Name of Patient's Primary Practitioner 
Physician Name 
265 1.6 Primary Care E12_05 Middle Name of Patient's Primary Practitioner 


Physician Name 
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Line # | VEDS element Element Code | OPHI-PCR Data Element X = Data 
(Red and Elements to be 
Yellow are Tested for 
NEMSIS Compliance 
elements (Red = Required 
collected by National Data 
the state) Elements) 

266 1.6 Primary Care E12 06 Last Name of Patient's Primary Practitioner 

Physician Name 

267 1.6 Living Will E12_07 Advanced Directives 

268 1.6 Allergies E12_08 Medication Allergies 

269 1.6 Allergies E12_09 Environmental/Food Allergies 

270 1.6 Medical History | E12_10 Medical/Surgical History 

271 E12 11 Medical History Obtained From 

272 E12 12 Immunization History 

273 E12 13 Immunization Date 

274 1.6 Medications E12 14 Current Medications 

275 1.6 Medications E12 15 Current Medication Dose 

276 1.6 Medications E12 16 Current Medication Dosage Unit 

277 1.6 Medications E12_17 Current Medication Administration Route 

278 1.6 Emergency E12 18 Presence of Emergency Information Form 

Contact 

279 E12 19 Alcohol/Drug Use Indicators X 

280 1.6 Pregnant E12 20 Pregnancy 

281 E13 01 Run Report Narrative 

282 E14 01 Date/Time Vital Signs Taken 

283 E14 02 Obtained Prior to this Units EMS Care 

284 E14 03 Cardiac Rhythm 

285 E14 04 SBP (Systolic Blood Pressure) 

286 E14 05 DBP (Diastolic Blood Pressure) 

287 E14 06 Method of Blood Pressure Measurement 

288 E14 07 Pulse Rate 

289 E14 08 Electronic Monitor Rate 

290 E14 09 Pulse Oximetry 

291 E14 10 Pulse Rhythm 

292 1.5 Breathing E14 11 Respiratory Rate 
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Line # | VEDS element Element Code | OPHI-PCR Data Element X = Data 
(Red and Elements to be 
Yellow are Tested for 
NEMSIS Compliance 
elements (Red = Required 
collected by National Data 
the state) Elements) 

293 1.5 Breathing E14 12 Respiratory Effort 

294 E14 13 Carbon Dioxide 

295 E14 14 Blood Glucose Level 

296 1.5 Conscious E14 15 Glasgow Coma Score-Eye 

297 1.5 Conscious E14 16 Glasgow Coma Score-Verbal 

298 1.5 Conscious E14 17 Glasgow Coma Score-Motor 

299 1.5 Conscious E14 18 Glasgow Coma Score-Qualifier 

300 1.5 Conscious E14 19 Total Glasgow Coma Score 

301 E14 20 Temperature 

302 E14 21 Temperature Method 

303 1.5 Conscious, E14 22 Level of Responsiveness 

Speaking 

304 E14 23 Pain Scale 

305 E14 24 Stroke Scale 

306 E14 25 Thrombolytic Screen 

307 1.5 Breathing E14 26 APGAR 

308 E14 27 Revised Trauma Score 

309 E14 28 Pediatric Trauma Score 

310 E15 01 NHTSA Injury Matrix External/Skin 

311 E15 02 NHTSA Injury Matrix Head 

312 E15 03 NHTSA Injury Matrix Face 

313 E15 04 NHTSA Injury Matrix Neck 

314 E15 05 NHTSA Injury Matrix Thorax 

315 E15 06 NHTSA Injury Matrix Abdomen 

316 E15 _07 NHTSA Injury Matrix Spine 

317 1.5 Moving Arm E15 _ 08 NHTSA Injury Matrix Upper Extremities 

318 E15 09 NHTSA Injury Matrix Pelvis 

319 1.5 Moving Leg E15 10 NHTSA Injury Matrix Lower Extremities 

320 E15 11 NHTSA Injury Matrix Unspecified 

321 E16 01 Estimated Body Weight 
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Line # | VEDS element Element Code | OPHI-PCR Data Element X = Data 
(Red and Elements to be 
Yellow are Tested for 
NEMSIS Compliance 
elements (Red = Required 
collected by National Data 
the state) Elements) 
322 E16 02 Broselow/Luten Color 
323 E16_03 Date/Time of Assessment 
324 1.5 External E16 04 Skin Assessment 
Bleeding 
325 1.5 External E16 05 Head/Face Assessment 
Bleeding 
326 1.5 External E16 06 Neck Assessment 
Bleeding 
327 1.5 External E16 _07 Chest/Lungs Assessment 
Bleeding 
328 1.5 External E16_08 Heart Assessment 
Bleeding 
329 1.5 External E16 09 Abdomen Left Upper Assessment 
Bleeding 
330 1.5 External E16 10 Abdomen Left Lower Assessment 
Bleeding 
331 1.5 External E16 11 Abdomen Right Upper Assessment 
Bleeding 
332 1.5 External E16 12 Abdomen Right Lower Assessment 
Bleeding 
333 1.5 External E16 13 GU Assessment 
Bleeding 
334 1.5 External E16 14 Back Cervical Assessment 
Bleeding 
335 1.5 External E16 15 Back Thoracic Assessment 
Bleeding 
336 1.5 External E16 16 Back Lumbar/Sacral Assessment 
Bleeding 
337 1.5 External E16 17 Extremities-Right Upper Assessment 
Bleeding, Moving 
Arm 
338 1.5 External E16 18 Extremities-Right Lower Assessment 


Bleeding, Moving 
Leg 
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Line # | VEDS element Element Code | OPHI-PCR Data Element X = Data 
(Red and Elements to be 
Yellow are Tested for 
NEMSIS Compliance 
elements (Red = Required 
collected by National Data 
the state) Elements) 
339 1.5 External E16 19 Extremities-Left Upper Assessment 
Bleeding, Moving 
Arm 
340 1.5 External E16_20 Extremities-Left Lower Assessment 
Bleeding, Moving 
Leg 
341 1.5 External E16 21 Eyes-Left Assessment 
Bleeding 
342 1.5 External E16 22 Eyes-Right Assessment 
Bleeding 
343 E16 23 Mental Status Assessment 
344 E16 24 Neurological Assessment 
345 E17_01 Protocols Used 
346 E18 01 Date/Time Medication Administered 
347 E18 02 Medication Administered Prior to this Units EMS Care 
348 E18 03 Medication Given X 
349 E18 04 Medication Administered Route 
350 E18 05 Medication Dosage 
351 E18 06 Medication Dosage Units 
352 E18 07 Response to Medication 
353 E18 08 Medication Complication X 
354 E18 09 Medication Crew Member ID 
355 E18 10 Medication Authorization 
356 E18 11 Medication Authorizing Physician 
357 E19 01 Date/Time Procedure Performed Successfully 
358 E19 02 Procedure Performed Prior to this Units EMS Care 
359 E19 03 Procedure X 
360 E19 04 Size of Procedure Equipment 
361 E19 05 Number of Procedure Attempts X 
362 E19 06 Procedure Successful X 
363 E19 07 Procedure Complication X 
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Line # | VEDS element Element Code | OPHI-PCR Data Element X = Data 
(Red and Elements to be 
Yellow are Tested for 
NEMSIS Compliance 
elements (Red = Required 
collected by National Data 
the state) Elements) 

364 E19 08 Response to Procedure 

365 E19 09 Procedure Crew Members ID 

366 E19 10 Procedure Authorization 

367 E19 11 Procedure Authorizing Physician 

368 E19 12 Successful IV Site 

369 E19 13 Tube Confirmation 

370 E19 14 Destination Confirmation of Tube Placement 

371 E20 01 Destination/Transferred To, Name 

372 E20 02 Destination/Transferred To, Code 

373 E20 03 Destination Street Address 

374 E20_04 Destination City 

375 E20_05 Destination State 

376 E20_06 Destination County 

377 E20 07 Destination Zip Code X 

378 E20_08 Destination GPS Location 

379 E20_09 Destination Zone Number 

380 E20_10 Incident/Patient Disposition X 

381 E20 11 How Patient Was Moved to Ambulance 

382 E20_12 Position of Patient During Transport 

383 E20 13 How Patient Was Transported From Ambulance 

384 E20 14 Transport Mode from Scene X 

385 E20 15 Condition of Patient at Destination 

386 E20 16 Reason for Choosing Destination X 

387 E20 17 Type of Destination X 

388 E21 01 Event Date/Time 

389 E21 02 Medical Device Event Name 

390 E21 03 Waveform Graphic Type 

391 E21 04 Waveform Graphic 

392 E21 05 AED, Pacing, or CO2 Mode 
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Line # | VEDS element Element Code | OPHI-PCR Data Element X = Data 
(Red and Elements to be 
Yellow are Tested for 
NEMSIS Compliance 
elements (Red = Required 
collected by National Data 
the state) Elements) 

393 E21_06 ECG Lead 

394 E21 07 ECG Interpretation 

395 E21 08 Type of Shock 

396 E21 09 Shock or Pacing Energy 

397 E21 10 Total Number of Shocks Delivered 

398 E21 11 Pacing Rate 

399 E21 12 Device Heart Rate 

400 E21 13 Device Pulse Rate 

401 E21 14 Device Systolic Blood Pressure 

402 E21 15 Device Diastolic Blood Pressure 

403 E21 16 Device Respiratory Rate 

404 E21 17 Device Pulse Oximetry 

405 E21 18 Device CO2 or etCO2 

406 E21 19 Device CO2, etCO2, or Invasive Pressure Monitor Units 

407 E21 20 Device Invasive Pressure Mean 

408 E22 01 Emergency Department Disposition X 

409 E22 02 Hospital Disposition X 

410 E22 03 Law Enforcement/Crash Report Number 

411 E22 04 Trauma Registry ID 

412 E22 05 Fire Incident Report Number 

413 E22 06 Patient ID Band/Tag Number 

414 E23 01 Review Requested 

415 E23 02 Potential Registry Candidate 

416 E23 03 Personal Protective Equipment Used 

417 E23 04 Suspected Intentional, or Unintentional Disaster 

418 E23 05 Suspected Contact with Blood/Body Fluids of EMS Injury or 

Death 

419 E23 06 Type of Suspected Blood/Body Fluid Exposure, Injury, or Death 

420 E23 07 Personnel Exposed 

421 E23 08 Required Reportable Conditions 
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(Red and Elements to be 
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NEMSIS Compliance 
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the state) Elements) 

422 E23 09 Research Survey Field 

423 E23 10 Who Generated this Report? 

424 E23 11 Research Survey Field Title 
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Line | VEDS SHEE | SHEET FIELD NAME FIELD TYPE | NULLA | DESCRIPTION 
# element T#H NAME BLE 
2 1 ACCIDEN | AC_ACCID_NO NUMBER(9 UNIQUE NUMBER ASSIGNED BY THE DATABASE (I.E. PRIMARY KEY) 
T ) 
3 1.1 1 ACCIDEN | AC_ACCID_ID CHAR(13) ACCIDENT NUMBER ASSIGNED BY THE REPORTING OFFICER. 
Incident # T 
4 1 ACCIDEN | AC_REPORT_FLAG CHAR(1) Y REPORT FLAG. (UNUSED) 
T 
5 1.2 1 ACCIDEN | AC_DATE DATE ACCIDENT DATE. 
Incident T 
Date/Time 
6 1.2 1 ACCIDEN | AC_CITY_CODE CHAR(3) Y CITY CODE. 
Location T 
Description 
7 1.2 1 ACCIDEN | AC_COUNTY_CODE CHAR(2) Y COUNTY CODE. 
Location af 
Description 
8 1 ACCIDEN | AC_GPS CHAR(16) Y GLOBAL POSITIONING INFORMATION.(UNUSED) 
T 
9 1 ACCIDEN | AC_LOCATION_TYPE CHAR(1) Y LOCATION TYPE. 
T 
10 1.2 1 ACCIDEN | AC_LOCATION CHAR(16) Y ACCIDENT LOCATION. 
Location T 
Description 
11 1 ACCIDEN | AC_DIST_FROM CHAR(5) Y ACCIDENT LOCATION DISTANCE FROM THE NEAREST MILEPOST. 
T 
12 1 ACCIDEN | AC_CITY_COORD CHAR(12) Y CITY GRID COORDINATES. 
T 
13 1 ACCIDEN | AC_RANGE_CODE CHAR(4) Y RANGE CODE. 
T 
14 1 ACCIDEN | AC_TOWNSHIP_CODE CHAR(3) Y TOWNSHIP CODE. 
T 
15 1 ACCIDEN | AC_SECTION_CODE CHAR(2) Y SECTION CODE. 
T 
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16 ACCIDEN | AC_ROUTE_ID CHAR(6) ROUTE ID. 
T 

17 ACCIDEN | AC_MILEPOST CHAR(4) MILEPOST. 
T 

18 ACCIDEN | AC_MILEPOST_DIR_CO | CHAR(1) MILEPOST DIRECTION CODE.(UNUSED) 
T DE 

19 ACCIDEN | AC_SPEED_LIMIT NUMBER(5 MAXIMUM SPEED LIMIT AT THE PLACE OF ACCIDENT. 
T ) 

20 ACCIDEN | AC_SPEED_UNIT_CODE | CHAR(1) SPEED UNIT CODE (MI/KM). 
T 

21 ACCIDEN | AC_TYPE_COLL_CODE CHAR(1) TYPE OF COLLISION. 
T 

22 ACCIDEN | AC_HIT_RUN_CODE CHAR(1) HIT AND RUN CODE. 
T 

23 ACCIDEN | AC_INJ_NUMB NUMBER(5 NUMER OF INJURIES. 
T ) 

24 ACCIDEN | AC_FATAL_NUMB NUMBER(5 NUMBER OF FATALITIES. 
T ) 

25 ACCIDEN | AC_VEH_NUMB NUMBER(5 NUMBER OF VEHICLES INVOLVED. 
I ) 

26 ACCIDEN | AC_PEDEST_NUMB NUMBER(5 NUMBER OF PEDESTRIANS INVOLVED. 
i. ) 

27 ACCIDEN | AC_CLASS TRFWAY_CO | CHAR(1) TRAFFICWAY CLASS CODE. 
T DE 

28 ACCIDEN | AC_ACCID_SEV_CODE CHAR(1) ACCIDENT SEVERITY CODE. 
T 

29 ACCIDEN | AC_DAMAGE_SEV_COD | CHAR(1) DAMAGE SEVERITY CODE.(UNUSED) 
T E 

30 1.4b ACCIDEN | AC_REL_RDWAY_CODE | CHAR(1) RELATION TO ROADWAY. 

Orientation T 

31 ACCIDEN | AC_REL_JUNC_CODE CHAR(1) JUNCTION RELATED CODE. 

T 
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32 ACCIDEN | AC_WEATH_COND_CO | CHAR(2) WEATHER CONDITION AT THE TIME OF ACCIDENT. 
uF DE 

33 ACCIDEN | AC_LIGHT_COND_COD | CHAR(1) LIGHT CONDITION AT THE TIME OF ACCIDENT. 
T E 

34 ACCIDEN | AC_ROAD_COND_COD | CHAR(1) CONDITIONS OF THE ROAD. 
Th E 

35 ACCIDEN | AC_TRAF_CONTLS_COD | CHAR(2) TRAFFIC CONTROLS. 
T E 

36 ACCIDEN | AC_GRADE_CODE CHAR(1) GRADE. 
a 

37 ACCIDEN | AC_CONSTR_ZONE_CO | CHAR(1) CONSTRUCTION ZONE CODE (IF IT WAS A CONSTRUCTION ZONE). 
T DE 

38 ACCIDEN | AC_SITE_STUDY CHAR(1) SITE STUDY. 
T 

39 ACCIDEN | AC_BIKEWAY_CODE CHAR(1) BIKEWAY TYPE. 
T 

40 ACCIDEN | AC_RESERVATION_COD | CHAR(1) RESERVATION AREA CODE. 
T E 

41 ACCIDEN | AC_OTHR_DAMAG_CO | CHAR(2) OTHER DAMAGE TYPE. 
T DE 

42 ACCIDEN | AC_OTHR_DAMAG_SEV | CHAR(1) OTHER DAMAGE SEVERITY. 
T ER_CODE 

43 ACCIDEN | AC_OTHR_DAMAG_O CHAR(1) OTHER DAMAGE OWNER. 
uF WNR_CODE 

44 ACCIDEN | AC_CC1_CODE CHAR(2) CONTRIBUTING CIRCUMSTANCE ONE.(UNUSED) 
T 

45 ACCIDEN | AC_CC2_CODE CHAR(2) CONTRIBUTING CIRCUMSTANCE TWO.(UNUSED) 
T 

46 ACCIDEN | AC_CC3_CODE CHAR(2) CONTRIBUTING CIRCUMSTANCE THREE.(UNUSED) 
T 

47 ACCIDEN | AC_CC4_CODE CHAR(2) CONTRIBUTING CIRCUMSTANCE FOUR.(UNUSED) 
T 
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48 ACCIDEN | AC_CC5_CODE CHAR(2) CONTRIBUTING CIRCUMSTANCE FIVE.(UNUSED) 
T 
49 ACCIDEN | AC_FIRST_HARM_COD | CHAR(2) FIRST HARMFUL EVENT.(UNUSED) 
T E 
50 ACCIDEN | AC_MOST_HARM_COD | CHAR(2) MOST HARMFUL EVENT.(UNUSED) 
T E 
51 ACCIDEN | AC_ALCOHOL CHAR(1) ALCOHOL INVOLVED.(UNUSED) 
T 
52 ACCIDEN | AC_BADGE_NO CHAR(4) BADGE_NO.(UNUSED) 
T 
53 ACCIDEN | AC_DETACH CODE CHAR(3) DETACH_CODE.(UNUSED) 
T 
54 ACCIDEN | AC_FUNCT_CLASS CHAR(1) FUNCTIONAL CODE.(UNUSED) 
T 
55 ACCIDEN | AC_NOTIF_DATE DATE NOTIFICATION DATE. 
T 
56 ACCIDEN | AC_ARRIV_DATE DATE ARRIVAL DATE. 
T: 
57 ACCIDEN | AC_ADHOC_PROJ1 CHAR(12) ADHOC PROJECT 1.(UNUSED) 
T 
58 ACCIDEN | AC_ADHOC_DATA1 CHAR(12) ADHOC DATA 1.(UNUSED) 
T 
59 ACCIDEN | AC_ADHOC_PROJ2 CHAR(12) ADHOC PROJECT 2.(UNUSED) 
T 
60 ACCIDEN | AC_ADHOC_DATA2 CHAR(12) ADHOC DATA 2.(UNUSED) 
T 
61 ACCIDEN | AC_CRE_DATE_TIME DATE CREATION DATE AND TIME. 
T 
62 ACCIDEN | AC_CRE_USER CHAR(8) CREATED BY USER. 
T: 
63 ACCIDEN | AC_UPD_DATE_TIME DATE UPDATED DATE AND TIME. 
T 
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64 ACCIDEN | AC_UPD_USER VARCHAR2 UPDATED BY USER. 
T (10) 
65 ACCIDEN | AC_SENT_DOJ DATE DATE SENT TO DEPARTMENT OF JUSTICE.(UNUSED) 
af 
66 ACCIDEN | AC_SENT_MDT DATE DATE SENT TO DEPARTMENT OF TRANSPORTATION. 
HE 
67 ACCIDEN | AC_COMMERCIAL_NU NUMBER(2 COMMERCIAL NUMBER. 
T MB ) 
68 1.4a ACCIDEN | AC_HAZMAT_NUMB NUMBER(2 WHAT HAZARDIOUS MATERIAL INVOLVED IN ACCIDENT. 
Hazardous T ) 
Materials 
69 ACCIDEN | AC_SHORT_FORM VARCHAR2 SHORT FORM ACCIDENT REPORT. 
Ti (1) 
70 ACCIDEN | AC_X_COORD NUMBER(1 X COORDINATE OF ACCIDENT. 
T 3,5) 
71 ACCIDEN | AC_Y_COORD NUMBER(1 Y COORDINATE OF ACCIDENT. 
T 3,5) 
72 ACCIDEN | AC_Z COORD NUMBER(9 Z COORDINATE OF ACCIDENT. 
T /A) 
73 ACCIDEN | AC_DC_ID VARCHAR2 CORRIDOR IDENTIFICATION OF ACCIDENT LOCATION 
T (15) 
74 ACCIDEN | AC_DC_ROADBED VARCHAR2 CORRIDOR ROADBED OF ACCIDENT LOCATION. 
T (1) 
75 ACCIDEN | AC_DC_MP NUMBER(4 CORRIDOR MILEPOST OF ACCIDENT LOCATION. 
T ) 
76 ACCIDEN | AC_DC_MP_OFFSET NUMBER(4 CORRIDOR MILEPOST OFFSET OF ACCIDENT LOCATION. 
T /3) 
77 ACCIDEN | AC_SYS_CLASS VARCHAR2 SYSTEM CLASSIFICATION OF ACCIDENT LOCATION. 
T (30) 
78 ACCIDEN | AC_DR_ID VARCHAR2 DEPARTMENTAL ROUTE IDENTIFICATION OF ACCIDENT LOCATION. 
T (15) 
79 ACCIDEN | AC_DR_ROADBED VARCHAR2 DEPARMTMENTAL ROUTE ROADBED OF ACCIDENT LOCATION. 
T (1) 
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80 ACCIDEN | AC_FIN_DISTRICT_ID VARCHAR2 FINANCIAL DISTRICT 
T (20) 
81 1.2 ACCIDEN | AC_LAT FLOAT LATITUDE 
Latitude al: 
82 1.2 ACCIDEN | AC_LON FLOAT LONGITUDE 
Longitude T 
83 1.2 ACCIDEN | AC_INPUT_DATA_TYPE | VARCHAR2 Field to indicate the format of data. XY COORDINATES or LAT LON 
Latitude, T (20) 
Longitude 
84 ACCIDEN | AC_MHP_UNIQUE_KEY | VARCHAR2 This is the unique key field to tie records to the new MHP system. 
T (22) 
85 ACCIDEN | AC_SUPPLEMENT_NO VARCHAR2 This field identifies if the record has been duplicated and the number of times. 01 
T (3) is the original. 
86 ACCIDEN | AC_OFFICER_DESC VARCHAR2 Officer Description of the location 
T (40) 
87 ACCIDEN | AC_OFFICER_AGENCY VARCHAR2 Officer Agency 
T (50) 
88 ACCIDEN | AC_OFFICER_ID VARCHAR2 Officer Badge ID 
T (10) 
89 ACCIDEN | AC_VIOLATION_COUNT | NUMBER(2 The number of violations given on this crash. 
T ) 
90 ACCIDEN | AC_ACCESS CONTROL VARCHAR2 How Access to the roadway is controlled 
T (2) 
91 VEHICLE | VE_VEH_NO NUMBER(9 PRIMARY KEY OF VEHICLE TABLE. 
) 
92 VEHICLE | VE_ACCID_NO NUMBER(9 SYSTEM ASSIGNED ACCIDENT PRIMARY KEY. 
) 
93 VEHICLE | VE_VEH_SEQ_NO NUMBER(5 THE VEHICLE NUMBER INVOLVED IN THE ACCIDENT. 
) 
94 1.4a VEHICLE | VE_PLATE_STATE_COD | CHAR(2) VEHICLE STATE. 
Owner's E 
State and 
Province 
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95 VEHICLE VE_PLATE_EXP_YEAR NUMBER(5 PLATE EXPERATION YEAR.(UNUSED) 
) 
96 1.4a Year VEHICLE VE_VEH_YEAR NUMBER(5 VEHICLE YEAR OF MANUFACTURE. 
) 
97 1.4a Body VEHICLE VE_VEH_MAKE CHAR(10) VEHICLE MAKE. 
Type 
98 1.4a Make VEHICLE VE_BODY_STYLE_CODE | CHAR(2) VEHICLE BODY STYLE CODE. 
99 VEHICLE VE_TRAILER_STYLE_CO | CHAR(2) TRAILER STYLE. 
DE 
100 | 1.4b VEHICLE VE_HEADING CHAR(1) DIRECTION OF TRAVEL. 
Heading 
101 VEHICLE VE_VEH_INTENT_CODE | CHAR(2) VEHICLE INTENT. 
102 VEHICLE VE_DAMAG_SEVER_CO | CHAR(1) DAMAGE SEVERITY. 
DE 
103 VEHICLE VE_DAMAG_AREA_CO CHAR(2) (UNUSED) 
DE 
104 VEHICLE VE_DEFORM_EXT_COD | CHAR(1) (UNUSED) 
E 
105 VEHICLE VE_TOW_CODE CHAR(1) TOWED DUE TO DAMAGE. 
106 VEHICLE VE_VIOL1_CODE VARCHAR2 VIOLATION NUMBER ONE. 
(30) 
107 VEHICLE VE_VIOL2_CODE VARCHAR2 VIOLATION NUMBER TWO. 
(30) 
108 VEHICLE VE_DL_STATE_CODE CHAR(2) DRIVERS LICENSE STATE. 
109 VEHICLE VE_DL_STATUS_CODE CHAR(1) DRIVERS LICENSE STATUS. 
110 VEHICLE VE_DL_CLASS_CODE CHAR(1) DRIVERS LICENSE CLASS CODE. 
111 VEHICLE VE_DL_COMPL_CODE CHAR(1) DRIVERS LICENSE RESTRICTION COMPLIANCE. 
112 VEHICLE VE_DL_OTHR_DATA CHAR(10) (UNUSED) 
113 VEHICLE VE_CC1_CODE CHAR(2) CONTRIBUTING CIRCUMSTANCE ONE. 
114 VEHICLE VE_CC2_CODE CHAR(2) CONTRIBUTING CIRCUMSTANCE TWO. 
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115 VEHICLE VE_CC3_CODE CHAR(2) CONTRIBUTING CIRCUMSTANCE THREE. 
116 VEHICLE VE_CC4_CODE CHAR(2) CONTRIBUTING CIRCUMSTANCE FOUR. 
117 VEHICLE VE_CC5_CODE CHAR(2) CONTRIBUTING CIRCUMSTANCE FIVE 
118 VEHICLE VE_FIRST_HARMFUL CHAR(2) FIRST HARMFUL EVENT. 
119 VEHICLE VE_MOST_HARMFUL CHAR(2) MOST HARMFUL EVENT. 
120 VEHICLE VE_ALCOHOL_DRUGS CHAR(1) USE OF ALCOHOL OR DRUGS.(UNUSED) 
121 VEHICLE VE_ALCOHOL CHAR(2) USE OF ALCOHOL.(UNUSED) 
122 VEHICLE VE_DRUGS CHAR(1) USE OF DRUGS.(UNUSED) 
123 VEHICLE VE_ADHOC_PROJ1 CHAR(12) ADHOC PROJECT 1.(UNUSED) 
124 VEHICLE VE_ADHOC_DATA1 CHAR(12) ADHOC DATA 1.(UNUSED) 
125 VEHICLE VE_ADHOC_PROJ2 CHAR(12) ADHOC PROJECT 2.(UNUSED) 
126 VEHICLE VE_ADHOC_DATA2 CHAR(12) ADHOC DATA 2.(UNUSED) 
127 VEHICLE VE_VEH_PED_FLAG CHAR(1) VEHICLE / PEDIESTRIAN FLAG "V". 
128 VEHICLE VE_CRE_DATE_TIME DATE CREATED DATE AND TIME. 
129 VEHICLE VE_CRE_USER CHAR(8) CREATED BY USER. 
130 VEHICLE VE_UPD_DATE_TIME DATE UPDATED DATE AND TIME. 
131 VEHICLE VE_UPD_USER CHAR(8) UPDATED BY USER. 
132 VEHICLE VE_COMMERCIAL_FLA CHAR(1) COMMERCIAL FLAG. 
G 
133 | 1.4a VEHICLE VE_HAZMAT_FLAG CHAR(1) HAZARDOUS MATERIAL INVOLVED IN ACCIDENT. 
Hazardous 
Materials 
134 VEHICLE VE_MHP_UNIQUE_KEY | VARCHAR2 THIS IS THE UNIQUE KEY TO TIE THE VECHICLE RECORDS TO THE MHP SYSTEM. 
(22) 
135 VEHICLE VE_MHP_UNIQUE_FKE | VARCHAR2 THIS IS THE FOREIGN KEY TO TIE THE VEHICLE RECORDS TO THE TRAFFIC CRASH 
Y (22) RECORDS. 
136 VEHICLE VE_VIOL1_DESC VARCHAR2 VIOLATION 1 DESCRIPTION 
(180) 
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137 VEHICLE VE_VIOL2_DESC VARCHAR2 VIOLATION 2 DESCRIPTION 
(180) 
138 VEHICLE VE_CMV_CONFIG VARCHAR2 COMMERCIAL MOTOR VECHICLE CONFIG 
(2) 
139 | 1.4a VEHICLE VE_GVW_RATING VARCHAR2 GROSS VEHICLE WEIGHT RATING 
Weight (2) 
140 VEHICLE VE_HAZ_MAT_NO VARCHAR2 HAZARDOUS MATERIALS MATERIAL NO 
(4) 
141 VEHICLE VE_TRAFFICWAY_DESC_ | VARCHAR2 TRAFFICWAY DESCRIPTION 
(2) 
142 OCCUPA OC_OCCUP_NO NUMBER(9 OCCUPANT NUMBER PRIMARY KEY OF THE TABLE. 
NT ) 
143 OCCUPA OC_ACCID_NO NUMBER(9 KEY FROM ACCIDENT TABLE AC_ACCID_NO KEY. 
NT ) 
144 OCCUPA OC_VEH_NO NUMBER(9 KEY FROM VEHICLE TABLE VE_ACCID_NO. 
NT ) 
145 OCCUPA OC_NAME_NO NUMBER(9 KEY FROM NAME TABLE NM_NAME_NO. 
NT ) 
146 OCCUPA OC_PEDEST_NO NUMBER(9 KEY FROM PEDESTRIAN TABLE PE_PEDEST_NO. 
NT ) 
147 | 1.5 Seat OCCUPA OC_SEAT_POS_CODE CHAR(2) SEATING POSITION. 
Position NT 
148 OCCUPA OC_INJ_TRANS_CODE CHAR(1) INJURED TRANSPORTATION. 
NT 
149 OCCUPA OC_INJ_CLASSIF_CODE CHAR(1) INJURY CLASSIFICATION. 
NT 
150 OCCUPA OC_ALCOHOL_DRUGS__ | CHAR(1) ALCOHOL OR DRUG USE. 
NT CODE 
151 | 1.4b Belt OCCUPA OC_BELTS_CODE CHAR(2) BELT CODE. 
Fastened NT 
152 | 1.4b OCCUPA OC_AIR_BAG_CODE CHAR(1) AIR BAG DEPLOYED. 
Deployed NT 
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153 | 1.5 Ejected OCCUPA OC_EJECT_CODE CHAR(1) EJECTION. 
NT 
154 | 1.5 OCCUPA OC_TRAP_EXTRAC_CO CHAR(1) TRAPPED / EXTRACTION. 
Entrapped NT DE 
155 | 1.5 OCCUPA OC_LAST_NAME CHAR(16) LAST NAME.(UNUSED) 
Occupant's NT 
Name 
156 | 1.5 OCCUPA OC_FIRST_NAME CHAR(10) FIRST NAME.(UNUSED) 
Occupant's NT 
Name 
157 | 1.5 OCCUPA OC_MIDDLE_INITIAL CHAR(1) MIDDLE INITIAL.(UNUSED) 
Occupant's NT 
Name 
158 | 1.5 OCCUPA OC_SEX_CODE CHAR(1) SEX CODE. 
Occupant's NT 
Gender 
159 | 1.5 OCCUPA OC_AGE NUMBER(5 AGE. 
Occupant's NT ) 
Age 
160 OCCUPA OC_CC1_CODE CHAR(2) CONTRIBUTING CIRCUMSTANCES ONE.(UNUSED) 
NT 
161 OCCUPA OC_CC2_CODE CHAR(2) CONTRIUBTING CIRCUMSTANCES TWO.(UNUSED) 
NT 
162 OCCUPA OC_ADHOC_PROJ1 CHAR(12) ADHOC PROJECT 1.(UNUSED) 
NT 
163 OCCUPA OC_ADHOC_DATA1 CHAR(12) ADHOC DATA 1.(UNUSED) 
NT 
164 OCCUPA OC_ADHOC_PROJ2 CHAR(12) ADHOC PROJECT 2.(UNUSED) 
NT 
165 OCCUPA OC_ADHOC_DATA2 CHAR(12) ADHOC DATA 2.(UNUSED) 
NT 
166 OCCUPA OC_VEH_PED_FLAG CHAR(1) VEHICLE OR PEDESTRIAN FLAG V OR P. 
NT 
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167 OCCUPA | OC_CRE_DATE_TIME DATE CREATED TIME AND DATE. 
NT 

168 OCCUPA | OC_CRE_USER CHAR(8) CREATED BY USER. 
NT 

169 OCCUPA | OC_UPD_DATE_TIME DATE UPDATE TIME AND DATE. 
NT 

170 OCCUPA | OC_UPD_USER CHAR(8) UPDATED BY USER. 
NT 

171 OCCUPA | OC_MHP_UNIQUE_KEY | VARCHAR2 THIS IS THE UNIQUE KEY TO TIE OCCUPANT RECORDS TO THE PERSON BUSINESS 
NT (22) RECORDS IN THE NEW MHP SYSTEM 

172 OCCUPA | OC_MHP_UNIQUE_TKE | VARCHAR2 THIS IS A FOREIGN KEY TO THE TRAFFIC CRASH TABLE IN THE NEW MHP SYSTEM. 
NT Y (22) 

173 OCCUPA | OC_MHP_UNIQUE_VKE | VARCHAR2 THIS IS A FOREIGN KEY TO THE VEHICLE TABLE IN THE NEW MHP SYSTEM. 
NT Y (22) 

174 PEDESTR | PE_PEDEST_NO NUMBER(9 PEDESTRIAN NUMBER PRIMARY KEY OF THE TABLE. 
IAN ) 

175 PEDESTR | PE_ACCID_NO NUMBER(9 SYSTEM ASSIGNED ACCIDENT PRIMARY KEY. 
IAN ) 

176 PEDESTR | PE_PEDEST_SEQ_NO NUMBER(5 PEDESTRIAN SEQUENCE NUMBER. 
IAN ) 

177 PEDESTR | PE_VIOL1_CODE CHAR(30) VIOLATION CODE ONE. 
IAN 

178 PEDESTR | PE_VIOL2_CODE CHAR(30) VIOLATION CODE TWO. 
IAN 

179 PEDESTR | PE_ACTIONS CHAR(2) ACTIONS OF THE PEDESTRIAN. 
IAN 

180 PEDESTR | PE_HEADING CHAR(1) DIRECTION OF TRAVEL. 
IAN 

181 PEDESTR | PE_CC1_CODE CHAR(2) CONTRIBUTING CIRCUMSTANCE ONE.(UNUSED) 
IAN 

182 PEDESTR | PE_CC2_CODE CHAR(2) CONTRIBUTING CIRCUMSTANCE TWO.(UNUSED) 
IAN 
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183 PEDESTR | PE_CC3_CODE CHAR(2) CONTRIBUTING CIRCUMSTANCE THREE.(UNUSED) 
IAN 
184 PEDESTR | PE_CC4_CODE CHAR(2) CONTRIBUTING CIRCUMSTANCE FOUR.(UNUSED) 
IAN 
185 PEDESTR | PE_CC5_CODE CHAR(2) CONTRIBUTING CIRCUMSTANCE FIVE.(UNUSED) 
IAN 
186 PEDESTR | PE_ALCOHOL_DRUGS | CHAR(1) USE OF ALCOHOL OR DRUGS.(UNUSED) 
IAN 
187 PEDESTR | PE_ALCOHOL CHAR(2) ALCOHOL USE.(UNUSED) 
IAN 
188 PEDESTR | PE_DRUGS CHAR(1) DRUG USE.(UNUSED) 
IAN 
189 PEDESTR | PE_ADHOC_PROJ1 CHAR(12) ADHOC PROJECT 1.(UNUSED) 
IAN 
190 PEDESTR | PE_ADHOC_DATA1 CHAR(12) ADHOC DATA 1.(UNUSED) 
IAN 
191 PEDESTR | PE_ADHOC_PROJ2 CHAR(12) ADHOC PROJECT 2.(UNUSED) 
IAN 
192 PEDESTR | PE_ADHOC_DATA2 CHAR(12) ADHOC DATA 2.(UNUSED) 
IAN 
193 PEDESTR | PE_VEH PED FLAG CHAR(1) VEHICLE / PEDESTRIAN FLAG "P". 
IAN 
194 PEDESTR | PE_CRE_DATE_TIME DATE CREATED TIME AND DATE. 
IAN 
195 PEDESTR | PE_CRE_USER CHAR(8) CREATED BY USER. 
IAN 
196 PEDESTR | PE_UPD_DATE_TIME DATE UPDATED TIME AND DATE. 
IAN 
197 PEDESTR | PE_UPD_USER CHAR(8) UPDATED BY USER. 
IAN 
198 PEDESTR | PE_MHP_UNIQUE_KEY | VARCHAR2 THIS IS THE UNIQUE KEY TO THE PERSON BUSINESS TABLE IN THE NEW MHP 
IAN (22) SYSTEM. 
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199 4 PEDESTR | PE_LMHP_UNIQUE_TKE | VARCHAR2 | Y THIS IS THE FOREIGN KEY TO THE TRAFFIC CRASH TABLE IN THE NEW MHP 
IAN Y (22) SYSTEM. 
200 4 PEDESTR | PE_VIOL1_DESC VARCHAR2 | Y VIOLATION 1 DESCRIPTION 
IAN (180) 
201 4 PEDESTR | PE_VIOL2_DESC VARCHAR2 | Y VIOLATION 2 DESCRIPTION 
IAN (180) 
Line # VEDS element | PK Name Data Type Nullable Description 
2 MCTSEND BIT ¥ True if the call was sent to MCT 
3 1.1 Incident # INCIDENTNO VARCHAR(15) Y Incident number for the call 
4 OFFENSENO VARCHAR(15) Y Offense number for the call 
5 CTYPE VARCHAR(1) ¥ Dispatch call type 
6 CMAP_OBJECT_NO INT ¥ Dispatch map object number 
7 CSTREETNO VARCHAR(8) Y Dispatch street number 
8 CSTREETDIR VARCHAR(2) Y Dispatch street direction 
9 CSTREET VARCHAR(30) Y Dispatch street name 
10 CAPTLOT VARCHAR(5) Y Dispatch apartment or suite 
11 CXSTREETDIR1 VARCHAR(2) Y Dispatch cross street direction 
12 CXSTREET1 VARCHAR(30) Y Dispatch cross street name 
13 CXSTREETDIR2 VARCHAR(2) Y Dispatch cross street direction 
14 CXSTREET2 VARCHAR(30) Y Dispatch cross street name 
15 CPLACE VARCHAR(55) 4 Dispatch place 
16 CIDIR1 VARCHAR(2) Y Dispatch location intersection direction 
17 CISTREET1 VARCHAR(30) Y Dispatch location intersection street 
18 CIDIR2 VARCHAR(2) Y Dispatch location intersection direction 
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Line # VEDS element | PK Name Data Type Nullable Description 
19 CISTREET2 VARCHAR(30) Y Dispatch location intersection street 
20 CINTERSTATE VARCHAR(4) Y Dispatch interstate location 
21 CBOUND VARCHAR(1) Y Dispatch bound in what direction 
22 CMM VARCHAR(4) Y Dispatch mile marker 
23 CEXIT VARCHAR(10) Y Dispatch interstate exit 
24 CENTRANCE VARCHAR(10) Y Dispatch interstate entrance 
25 COVERPASS VARCHAR(10) ¥ Dispatch overpass location 
26 CUNDERPASS VARCHAR(10) Y Dispatch underpass location 
27 CXINTERSTATE VARCHAR(4) Y Dispatch cross interstate 
28 CHIGHWAY VARCHAR(30) Y Dispatch highway location 
29 CMILES VARCHAR(4) Y Dispatch highway miles to 
30 CFROM VARCHAR(30) Y Dispatch from location 
31 CTOWARDS VARCHAR(30) Y Dispatch on highway, towards location 
32 COTHER_LOCATION VARCHAR(55) Y Dispatch other location 
33 CCITY VARCHAR(18) Y Dispatch City 
34 CSTATE VARCHAR(2) Y Dispatch state 
35 CZIP VARCHAR(5) Y Dispatch zip code 
36 CGEO_PRIMARY_AREA VARCHAR(4) Y Dispatch primary geo area 
37 CGEO_WRECKER_AREA VARCHAR(4) Y Dispatch wrecker are 
38 CGEO_LAW_SUB1 VARCHAR(4) Y Dispatch law geo sub area 
39 CGEO_LAW_SUB2 VARCHAR(4) Y Dispatch law geo sub area 
40 CGEO_LAW_SUB3 VARCHAR(4) Y Dispatch law geo sub area 
41 CGEO_FIRE_SUB1 VARCHAR(4) Y Dispatch fire geo sub area 
42 CGEO_FIRE_SUB2 VARCHAR(4) Y Dispatch fire geo sub area 
43 CGEO_FIRE_SUB3 VARCHAR(4) Y Dispatch fire geo sub area 
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Line # VEDS element | PK Name Data Type Nullable Description 

44 CGEO_EMS_SUB1 VARCHAR(4) Y Dispatch EMS geo sub area 

45 CGEO_EMS_SUB2 VARCHAR(4) Y Dispatch EMS geo sub area 

46 CGEO_EMS_SUB3 VARCHAR(4) Y Dispatch EMS geo sub area 

47 CMAP_X FLOAT Y Dispatch latitude 

48 CMAP_Y FLOAT Y Dispatch longitude 

49 CDIR TEXT Y Dispatch directions 

50 DTYPE VARCHAR(1) Y Occurrence call type 

51 1.2 Location DMAP_OBJECT_NO INT Y Occurrence map object number 
Description, 
Datum 

52 1.2 Location DSTREETNO VARCHAR(8) Y Occurrence street number 
Description 

53 1.2 Location DSTREETDIR VARCHAR(2) Y Occurrence street direction 
Description 

54 1.2 Location DSTREET VARCHAR(30) Y Occurrence street name 
Description 

55 1.2 Location DAPTLOT VARCHAR(5) Y Occurrence street apartment or suite 
Description 

56 1.2 Location DXSTREETDIR1 VARCHAR(2) Y Occurrence cross street direction 
Description 

57 1.2 Location DXSTREET1 VARCHAR(30) Y Occurrence cross street name 
Description 

58 1.2 Location DXSTREETDIR2 VARCHAR(2) Y Occurrence cross street direction 
Description 

59 1.2 Location DXSTREET2 VARCHAR(30) Y Occurrence cross street name 
Description 
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Line # VEDS element | PK Name Data Type Nullable Description 

60 1.2 Location DPLACE VARCHAR(55) Y Occurrence place name 
Description 

61 1.2 Location DIDIR1 VARCHAR(2) Y Occurrence location intersection direction 
Description 

62 1.2 Location DISTREET1 VARCHAR(30) Y Occurrence location intersection street 
Description 

63 1.2 Location DIDIR2 VARCHAR(2) Y Occurrence location intersection direction 
Description 

64 1.2 Location DISTREET2 VARCHAR(30) Y Occurrence location intersection street 
Description 

65 1.2 Location DINTERSTATE VARCHAR(4) Y Occurrence interstate location 
Description 

66 1.2 Heading DBOUND VARCHAR(1) Y Occurrence direction bound 

67 1.2 Location DMM VARCHAR(4) Y Occurrence mile marker 
Description 

68 1.2 Location DEXIT VARCHAR(10) Y Occurrence interstate exit location 
Description 

69 1.2 Location DENTRANCE VARCHAR(10) Y Occurrence interstate entrance location 
Description 

70 1.2 Location DOVERPASS VARCHAR(10) Y Occurrence overpass location 
Description 

71 1.2 Location DUNDERPASS VARCHAR(10) Y Occurrence underpass location 
Description 

72 1.2 Location DXINTERSTATE VARCHAR(4) Y Occurrence cross interstate 
Description 

73 1.2 Location DHIGHWAY VARCHAR(30) Y Occurrence highway 
Description 
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Line # VEDS element | PK Name Data Type Nullable Description 

74 1.2 Location DMILES VARCHAR(4) Y Occurrence miles distance 
Description 

75 1.2 Location DFROM VARCHAR(30) Y Occurrence Highway from location 
Description 

76 1.2 Location DTOWARDS VARCHAR(30) Y Occurrence highway towards location 
Description 

77 1.2 Location DOTHER_LOCATION VARCHAR(55) Y Occurrence other location 
Description 

78 1.2 Location DCITY VARCHAR(18) Y Occurrence city 
Description 

79 1.2 Location DSTATE VARCHAR(2) Y Occurrence state 
Description 

80 1.2 Location DZIP VARCHAR(5) Y Occurrence zip code 
Description 

81 1.2 Location DGEO_PRIMARY_AREA VARCHAR(4) Y Occurrence geo primary area 
Description 

82 1.2 Location DGEO_LAW_SUB1 VARCHAR(4) Y Occurrence geo law sub area 
Description 

83 1.2 Location DGEO_LAW_SUB2 VARCHAR(4) Y Occurrence geo law sub area 
Description 

84 1.2 Location DGEO_LAW_SUB3 VARCHAR(4) Y Occurrence geo law sub area 
Description 

85 1.2 Location DGEO_FIRE_SUB1 VARCHAR(4) Y Occurrence geo fire sub area 
Description 

86 1.2 Location DGEO_FIRE_SUB2 VARCHAR(4) Y Occurrence geo fire sub area 
Description 

87 1.2 Location DGEO_FIRE_SUB3 VARCHAR(4) Y Occurrence geo fire sub area 
Description 
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Line # VEDS element | PK Name Data Type Nullable Description 
88 1.2 Location DGEO_EMS_SUB1 VARCHAR(4) Y Occurrence geo EMS sub area 
Description 
89 1.2 Location DGEO_EMS_SUB2 VARCHAR(4) Y Occurrence geo EMS sub area 
Description 
90 1.2 Location DGEO_EMS_SUB3 VARCHAR(4) ¥ Occurrence geo EMS sub area 
Description 
91 1.2 Location DMAP_X FLOAT Y Occurrence latitude 
Description, 
Latitude 
92 1.2 Location DMAP_Y FLOAT Y Occurrence longitude 
Description, 
Longitude 
93 DDIR TEXT Y Occurrence location direction 
94 DOCCUR_IS_ DISPATCH BIT Y True if the occurrence is the same as the dispatch area 
95 COMPLAINT VARCHAR(20) Y Complaint 
96 COMPLAINT_ADDINFO VARCHAR(15) Y Complaint additional info 
97 COMPLAINT_STATUS VARCHAR(20) Y Complaint status 
98 COMPLAINT_LAW BIT Y True if this is a law complaint 
99 COMPLAINT_FIRE BIT Y True if this is a fire complaint 
100 COMPLAINT_EMS BIT Y True if this is a EMS complaint 
101 COMPLAINT_PUBLIC BIT Y True if this call is for public view 
102 COMPLAINT_TSDR BIT Y True if this is a TSDR complaint 
103 COMPLAINT_CRASH BIT Y True if this is a crash complaint 
104 COMPLAINT_OTHER BIT Y True if this is other complaint 
105 COMPLAINT_DUPLICATES BIT Y True if there is a duplicate compliant 
106 PRIORITY VARCHAR(1) Y Priority of the call 
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Line # VEDS element | PK Name Data Type Nullable Description 
107 ALARM BIT Y True if this an alarm call 
108 WEAPON VARCHAR(10) Y Weapon used in the complaint 
109 1.1 Provider CNAME VARCHAR(30) Y Complainant name 

Name 
110 1.1 Call back # CPHONE VARCHAR(13) Y Complainant phone number 
111 CCONTACT VARCHAR(1) Y Complainant contact - Y or N 
112 1.1 Provider c911 VARCHAR(1) Y Complainant 911 call - Y or N 

Name 
113 PUNIT VARCHAR(5) Y Primary unit 
114 PUNITA VARCHAR(4) Y Primary unit agency 
115 PUNITPERNO VARCHAR(15) Y Primary unit personnel number 
116 1.2 Receive DRECV DATETIME Y Date call received 

Date/Time of 

Incident 
117 1.2 Receive TRECV DATETIME Y Time call received 

Date/Time of 

Incident 
118 DRECV_C VARCHAR(10) Y String value of the DRECV Field 
119 TRECV_C VARCHAR(8) Y String value of the TRECV Field 
120 DSHIP DATETIME ¥ Date call was shipped to unit 
121 TSHIP DATETIME Y Time call was shipped to unit 
122 DDISP DATETIME Y Date call was disposed 
123 TDISP DATETIME Y Time call was disposed 
124 D1051 DATETIME Y Date unit was enroute 
125 T1051 DATETIME Y Time unit was put on enroute 
126 D1097 DATETIME Y Date unit was placed on scene 
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Line # VEDS element | PK Name Data Type Nullable Description 
127 T1097 DATETIME Y Time unit was placed on scene 
128 D1098 DATETIME Y Date call was closed 
129 T1098 DATETIME Y Time call was closed 
130 CLOSED VARCHAR(1) Y Closed code 
131 CODE_DATE DATETIME Y Date call was coded closed 
132 CODE_TIME DATETIME Y Time call was coded closed 
133 CODE1 VARCHAR(4) Y Code 1 for call disposition 
134 CODE1_REASON VARCHAR(50) Y Reason the call was closed 
135 CODE1_LAW BIT Y True if call was closed as law call 
136 CODE1_FIRE BIT Y True if call was closed as fire call 
137 CODE1_EMS BIT Y True if call was closed as EMS call 
138 CODE1_OTHER BIT Y True if call was closed as other call 
139 CODE1_TSDR BIT Y True if call was closed as a TSDR call 
140 CODE2 VARCHAR(4) Y Code 2 for call disposition 
141 CODE2_REASON VARCHAR(50) Y Reason the call was closed 
142 CODE3 VARCHAR(4) Y Code 3 for call disposition 
143 CODE3_REASON VARCHAR(50) Y Reason the call was closed 
144 CODE4 VARCHAR(4) Y Code 4 for call disposition 
145 CODE4_REASON VARCHAR(50) Y Reason the call was closed 
146 CODES VARCHAR(4) Y Code 5 for call disposition 
147 CODE5_REASON VARCHAR(50) Y Reason the call was closed 
148 CODE6 VARCHAR(4) Y Code 6 for call disposition 
149 CODE6_REASON VARCHAR(50) Y Reason the call was closed 
150 CALLTAKER VARCHAR(10) Y Call taker for the call 
151 DISPATCHER VARCHAR(10) Y Dispatcher of the call 
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Line # VEDS element | PK Name Data Type Nullable Description 

152 SUSPEND BIT Y True if the call was suspended 

153 SUSPEND_DATE DATETIME Y Date call was suspended 

154 SUSPEND_TIME DATETIME Y Time call was suspended 

155 FLAG_CWO BIT Y True if there was dispatch watch order 

156 FLAG_CPC BIT Y True if there was a dispatch prior call 

157 FLAG_CPX BIT Y True if there are prior calls for the dispatch location 

158 FLAG_CCN BIT Y True if there are caution notes on the dispatch 
location 

159 FLAG_CTW BIT Y True if there are trespass warnings for dispatch 
location 

160 FLAG_CDIR BIT Y True if there are directions to the dispatch location 

161 FLAG_CDUP BIT Y True if there are duplicate calls for this dispatch 
location 

162 FLAG_DWO BIT Y True if there is watch order on the occurrence address 

163 FLAG_DPC BIT Y True if there are prior calls for the occurrence location 

164 FLAG_DPX BIT Y True if there are prior calls for the occurrence location 

165 FLAG_DCN BIT v4 True if there are caution notes on the occurrence 
location 

166 FLAG_DTW BIT Y True if there are trespass warnings for occurrence 
location 

167 FLAG_DDIR BIT Y True if there are directions to the occurrence location 
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Line # VEDS element | PK Name Data Type Nullable Description 

168 FLAG_DDUP BIT Y True if there are duplicate calls for this occurrence 
location 

169 FLAG_TPC BIT Y True if there are Vehicle Priors 

170 FLAG_TCN BIT Y True if there are Vehicle Caution Note 

171 FLAG_TTL BIT Y True if there are Vehicle Tow 

172 FLAG_TBO BIT Y True if there are Vehicle BOLO (Be on the lookout) 

173 FLAG_AN BIT Y True if there is a call note 

174 FLAG_ERUN BIT Y True if there is a EMS Run Card for call (not used) 

175 FLAG_FRUN BIT Y True if there is a Fire Run Card for call (not used) 

176 FLAG_LRUN BIT Y True if there is a Law Run Card for call (not used) 

177 FLAG_DUP BIT ¥, True if there is a Duplicate call 

178 FLAG_SOP BIT ¥ rue if there is a SOP record exists for call's complaint 

179 FLAG_MED BIT Y True if there is a Medical record exists for call's 
complaint 

180 LOCATION_DISPLAY VARCHAR(80) Y The main screen displays this field, it is a combination 
of the main street with the cross streets 

181 LAST_REFRESH_DATE DATETIME Y Last refresh date 

182 LAST_REFRESH_TIME DATETIME Y Last refresh time 

183 RMS_EXPORT_LAW BIT Y This field is not used 

184 RMS_EXPORT_FIRE BIT Y This field is not used 

185 RMS_EXPORT_EMS BIT Y This field is not used 
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Line # VEDS element | PK Name Data Type Nullable Description 
186 RMS_EXPORT_OTHER BIT Y This field is not used 
187 e UNIQUEKEY VARCHAR(22) N Primary key for the record 
188 UCR_CODE1 VARCHAR(4) Y UCR Code1 
189 UCR_CODE2 VARCHAR(4) Y UCR Code2 
190 UCR_CODE3 VARCHAR(4) Y UCR Code3 
191 UCR_CODE4 VARCHAR(4) Y UCR Code4 
192 UCR_CODES5 VARCHAR(4) Y UCR Code5 
193 UCR_CODE6 VARCHAR(4) Y UCR Code6 
194 UCR_DESCRIPT1 VARCHAR(100) Y UCR description for the code 
195 UCR_DESCRIPT2 VARCHAR(100) Y UCR description for the code 
196 UCR_DESCRIPT3 VARCHAR(100) Y UCR description for the code 
197 UCR_DESCRIPT4 VARCHAR(100) Y UCR description for the code 
198 UCR_DESCRIPT5 VARCHAR(100) Y UCR description for the code 
199 UCR_DESCRIPT6 VARCHAR(100) Y UCR description for the code 
200 GMT_OFFSET INT Y Greenwich mean time offset 
201 1.1 Provider AGENCY VARCHAR(4) Y Agency for the call 
Name 
202 RUNIT VARCHAR(5) Y Reporting unit 
203 RUNITA VARCHAR(4) Y Reporting unit agency 
204 RUNITPERNO VARCHAR(15) Y Reporting unit personnel number 
205 FLAG_VALIDATED BIT Y True if the main address has been validated 
206 FLAG_MCT_INITIATED BIT Y True if an MCT sent this call in 
207 C911 TYPE INT Y 911 call type 
208 CICITY BIT Y True if the Dispatch occurred inside an incorporated 


city 


Data Book 


184 


Line # VEDS element | PK Name Data Type Nullable Description 
209 DICITY BIT Y True if the occurrence occurred inside an incorporated 
city 

210 CCOUNTY VARCHAR(35) Y Dispatch county 

211 DCOUNTY VARCHAR(35) Y Occurrence county 

212 CVALIDATED BIT Y Dispatch location validated 

213 DVALIDATED BIT Y Occurrence location validated 

214 CADDRESS1 VARCHAR(55) Y Dispatch address 

215 CADDRESS2 VARCHAR(55) x Dispatch address 

216 1.2 Location DADDRESS1 VARCHAR(55) Y Occurrence address 
Description 

217 1.2 Location DADDRESS2 VARCHAR(55) Y Occurrence address 
Description 

218 CGEOKEY VARCHAR(22) Y Dispatch geo key 

219 DGEOKEY VARCHAR(22) Y Occurrence geo key 

220 COMPLAINT_NONCAD BIT Y Non CAD complaint 

221 PUNITR VARCHAR(15) Y Primary unit agency 

222 RUNITR VARCHAR(15) Y Backup unit perno 

223 CALL_ORIGIN VARCHAR(25) Y Call Orgin 

224 QUNIT VARCHAR(5) Y Q Unit 

225 CEXT VARCHAR(10) Y Dispatch location extension 

226 ALARM_LEVEL INT v4 Alarm Level 

227 FLAG_NOTIFICATION_LIST BIT Y Flag notification list 

228 LAST_CHANGE_BY VARCHAR(10) Y User who last changed record 

229 FLAG_APCO BIT N True if APCO 

230 APCO_IN_PROGRESS BIT N APCO is in progress 
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Appendix D - Test Script 


Test Scenario: 


AACN Data Script for Simulated OnStar ‘Test Call’ 


May 3, 2012 


A (simulated) crash involving two vehicles occurs in a rural part of Missoula County, 


Montana. One of the two vehicles is equipped with OnStar AACN. The other vehicle is not. The OnStar 
Advisor, in talking with the driver of the OnStar vehicle, determines that there are at least two people in 
the OnStar vehicle, both of whom are injured. No information on the other vehicle is available. 


Test Call Data from OnStar Surrogate (Chris L) Standard Data Currently Captured by PSAP Call Taker 


during OnStar Call 


Table Cl 


4. Standard Data - Currently received or acquired by PSAP Call Taker from OnStar Caller 


Item 


Sample input 


Notes 


Caller Name 


OnStar TEST 


CAD data field automatically populated (Priority Access Phase 1) 


Call Back Number 800-xxx-yyyy CAD data field automatically populated (Priority Access Phase 1) 

Vehicle Make Chevrolet Verbally acquired; entered into CAD / Comment Field 

Vehicle Model Malibu Verbally acquired; entered into CAD / Comment Field 

OnStar Case Number | 125489017 Verbally acquired; entered into Comment Field 

PSAP Call Date mo/day/year CAD data field automatically populated 

PSAP Call Time hr:min CAD data field automatically populated 

Incident Street 7938 Grant Creek Rd | Verbally acquired; entered into CAD 

Incident City Missoula Verbally acquired; entered into CAD 

Number Injured 2 Verbally acquired (if TSP contact with vehicle occupants); entered in CAD 


5. Additional AACN Parameters - Verbally requested from OnStar and entered in PSAP ‘Comment Field’ 


using pre-defined notation (2" column) below: 


Item Sample input Notes 

Injury Severity Prediction ISP HIGH Reported (by OnStar) as HIGH or LOW (but computed as percentage). 

Multiple Impacts? MIMP No 

Crash Delta Velocity (mph) | DV1 25 Units are miles/hour. (Can be a DV2 if Multiple Impacts (1.e. if MIMP Yes) 

Direction of Impact DIR IMP1 Choices are Front, Right, Left, or Rear. (Can be a DIR IMP2 if MIMP=Y; 
from Right Here only first (or max) impact delta V and direction recorded) 

Rollover? Rollover Yes See Note** 

Time of Alert (hrs:min) Time alert received at TSP (OnStar). 


6. Other Test Data ‘Acquired’ by EMS (simulated at scene) 
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Activities at Missoula 9-1-1 PSAP during MT AACN Test Call 


May 3, 2012 


OnStar Surrogate 


PSAP Call Taker 


MT AACN Team Member 


e Arrive at PSAP at 9:45 am. Meet 
Chris Lounsbury & John Weber 
(Police). 


e Review planned test call activities. 


e Call 9-1-1 


e Wait for cell phone notification from 
all stations indicating players are in 
place. Inform Chris when ready. 


e Identify call as an ‘OnStar 
Test Call’ 


e Provide standard OnStar call 
information (see Table Cl 
‘Standard Data’) 


e Record standard call information in 
CAD including Make/Model of 
OnStar Vehicle 


e Send Dispatch request to MESI and 
Life Flight, noting that this is a 
TEST. 


e Provide PSAP call taker with 
additional AACN 
information (Attach A 
‘Additional) 


e Return to OnStar Advisor. Request 
rest of AACN information (see 
Table Cl ‘Additional Data’). 


e Record additional AACN 
parameters in Comment Field in 
prescribed format. 


e Monitor call until word received 
that test is over. 


e Request copy of CAD Status screen 


(& audio) for test documentation. 


Post Event — PSAP Staff 


e Go to MT-AACN website 
https://montana-aacn.cubre.org. 
View simulated crash records. 


e Ask posttest survey questions. 


e Run software script to extract 
OnStar crash data from PSAP 
database. 


e Emails crash record to CUBRC. 
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Activities at MESI Ground Ambulance during MT AACN Test Call 


May 3, 2012 


MESI Comm 


MESI Medic 


MT AACN Team Member 


e Arrive at MESI at 9:45 am. 
Meet Don Whalen. 


e Monitor CAD Status 
for appearance of 
additional AACN 
info. 


Receive dispatch message (via Pager, Radio) 
from Missoula 9-1-1 requesting (simulated) 
MESI response to an OnStar crash involving 
multiple vehicles. 


During (simulated) response to scene, monitor 
CAD Status on ToughBook. Note ISP (Injury 
Severity Prediction) and other OnStar AACN 
info. Also note make/model of OnStar-equipped 
vehicle 


e Review planned test call 
activities. When all players 
ready, call team member (via 
cell phone) at PSAP. 


Upon (simulated) arrival at scene, determine that 
patient to be transported by MESI was in Chevy 
Malibu (OnStar vehicle)*. This confirms ISP (& 
other AACN info) applies to MESI patient. 


Call Community Medical Center Charge Nurse 
with simulated en route patient info. (Make up 
age, gender, injuries/vitals). Tell nurse this was 
OnStar crash, patient was in Chevy Malibu, 
ISP=HIGH 


After (simulated) patient delivery to ER staff at 
St Pats, describe how patient AACN info and 
vehicle make/model might be documented in 
patient pre-hospital report. 


Post Event 


Go to MT-AACN website https://montana- 
aacn.cubre.org. View simulated crash records 
including one similar to test call** 


e Request copy of CAD Status 
screen & pre-hospital report 
form for test documentation. 


e Ask follow up survey 
questions. 


*In actual event, police or first responder at scene can identify make/model of patient vehicle and verbally 


communicate this to medic. 


**Data from OnStar AACN crash records will be extracted from Missoula 9 1-1 database by PSAP staff at regular 
(TBD) intervals and posted to website. 
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Test Call Activities at LifeFlight during MT AACN Test Call 


May 3, 2012 


Life Flight Comm 
(Spokane) 


Life Flight Medical Crew (Missoula) 


MT AACN Team Member 


e Arrive at St Pat’s ED at 9:45 
am. Call Larry Peterman 


e Review planned test call 
activities. Go to CAD Status 
location (Flight Room). 
When all players ready, 
inform team member (via cell 
phone) at PSAP. 


e Receive message from 
Missoula 9-1-1 PSAP 
requesting (simulated) 
Life Flight response to an 
OnStar crash. Monitor 


CAD Status (if available). 


e Assume weather is good & flight is accepted; 
view CAD Status in Flight Room while 
(simulated) preflight is underway. Note ISP, 
other OnStar AACN info and make/model of 
OnStar vehicle. 


e Upon (simulated) arrival at scene, determine 
that patient to be transported was occupant in 
Chevy Malibu (OnStar vehicle)*. Therefore 
ISP (& other AACN info) applies to Life Flight 


patient. 


e Call St Pat’s Charge Nurse with simulated en 
route patient info. (Make up age, gender, 
injuries). Tell charge nurse that patient was in 
OnStar crash, in Chevy Malibu & ISP is HIGH. 


(May also convey info upon arrival at hospital.) 


e After (simulated) patient delivery to ER staff at 
St Pats, describe how patient AACN info and 
vehicle make/model might be documented in 
patient pre-hospital report. 


e Post Event 


e Access MT-AACN website https://montana- 
aacn.cubrc.org. View simulated crash record 
from test call**. 


e Request copy of CAD Status 
screen and pre-hospital report 
form for test documentation. 


e Ask follow up survey 
questions. 


*In actual event, police or first responder at scene can identify make/model of patient vehicle and verbally 
communicate this to medic. 
**Data from OnStar AACN crash records will be extracted from Missoula 9-1-1 center database at regular (TBD) 
intervals and posted to website. 
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Test Call Activities at St. Patrick’s Hospital during MT AACN Test Call 


May 3, 2012 
Trauma Nurse Coordinator Hospital Charge Nurse MT AACN Team Member 
e Meet John Bleicher at ED at 9:45 
am 


Monitor CAD Status display for 


first appearance of simulated 
OnStar crash event. Note 
make/model of OnStar vehicle, ISP 
and other AACN info. 


e Go to CAD Status location. 
Review planned test call 
activities. When all players are 
ready, inform team member (via 
cell phone) at PSAP. 


Receive an en route call from Life 
Flight medic simulating transport 
of crash victim. Medic will provide 
usual patient status info. During 
this call (or upon hospital arrival), 
medic will indicate this was an 
OnStar crash, patient was in the 
Chevy Malibu and ISP is HIGH. 


Since patient vehicle matches 
make/model of OnStar vehicle on 
CAD Status, now confirmed that 
AACN info (and ISP) applies to 
incoming patient. 


Is there a mechanism for including 
patient vehicle make/model in 
patient trauma record? 


Put copy of CAD Status screen in 
patient trauma record. 


e Request copy of CAD Status 
screen for test documentation. A 
copy of patient trauma record 
form is also desirable. 


-Event 


https://montana-aacn.cubrce.org 
View AACN data** during patient 


record review at discharge. (CFSNo on 


CAD Status screen IDs crash record) 


e Ask posttest survey questions. 


(TBD) intervals and posted to website. 
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**Data from OnStar AACN crash records will be extracted from Missoula 9-1-1 database by PSAP staff at regular 


Activities at Community Medical Center during MT AACN Test Call 


May 3, 2012 


Trauma Nurse Coordinator 


Hospital Charge Nurse 


MT AACN Team Member 


e Meet Jon Stred at ED at 9:45 am. 


Monitor CAD Status display for 


first appearance of simulated 
OnStar crash event. Note 
make/model of OnStar vehicle, 
ISP and other AACN info. 


¢ Go to CAD Status location. 
Review planned test call 
activities. When all players are 
ready, inform team member (via 
cell phone) at PSAP. 


Receive an en route call from 
MESI medic simulating transport 
of crash victim. Medic will 
provide usual patient info and 
indicate this was OnStar crash, 
patient was in Chevy Malibu, and 
ISP = HIGH 


Since patient vehicle matches 
make/ model of OnStar vehicle on 
CAD Status, now confirmed that 
AACN info applies to incoming 
patient. 


Document patient vehicle 
make/model on ambulance call 
report with other usual info 
(mechanism of injury, vitals, 
treatment). 


As per protocol, scan ambulance 
call report (simulated) and put in 
patient record. Include copy of 
CAD Status screen in patient 
record. 


e Request copy of CAD Status 
screen & ambulance call report 
for test documentation. 


Post-Event 


e https://montana-aacn.cubrc.org 


View simulated crash record ** 


e Ask posttest survey questions. 


e (Clarity of CAD Status Screen) 


*In actual event, police or first responder at scene can identify make/model of patient vehicle and verbally 


communicate this to medic. 


**Data from OnStar AACN crash records will be extracted from Missoula 9-1-1 database by PSAP staff at regular 


(TBD) intervals and posted to website. 
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Appendix E - MT AACN Crash Telemetry Reports 


Website User Guide 


Cu: 


Montana Advanced Automatic Crash Notification (MT AACN) 
Crash Telemetry Reports 
Website User Guide 


http://montana-aacn.cubrc.or 


Prepared by 


Tom Fusillo & Marie Flanigan 
CUBRC 
4455 Genesee St 
Buffalo, NY 14225 


February 15, 2013 


192 


1. Introduction 


This manual explains the functionality provided to an end user using the Montana Advanced Automatic 
Crash Notification (AACN) Crash Telemetry Reports web application. This application provides a 
mechanism for archiving telemetry data in the MT AACN Database, as well as providing a portal for 
registered users to view the data post-event. 


1.1 Objectives 
The application was created to automatically receive and display crash telemetry data obtained from 
Missoula County’s 9-1-1 call records, which now document crash data obtained from motor vehicles in 
Missoula County that are equipped with AACN technology and experience a significant crash event. With 
the creation of this application, it is hoped Montana’s medical community can gain familiarity with AACN 
crash telemetry data and the use of such data to predict the likelihood of a serious injury. Understanding 
the utility of this data is important because: 
e Injury prediction will help support future medical direction, triage, and transport decision- 
making in real time. 
e AACN data can be linked with pre-hospital and hospital patient care records, providing 
supplemental data for future use in assessing effectiveness of various treatments and overall 
trauma system response. 


2. Getting Started 


2.1 Terminology and Definitions 

The event records displayed are initially acquired from a Telematics Service Provider (TSP), such as 
OnStar, who notifies the Missoula County 9-1-1 Public Safety Answering Point (PSAP) upon receipt of an 
AACN telematics call from their county. The PSAP call taker will initiate the dispatch of emergency 
vehicles, if necessary, and then collect the AACN data from the TSP. Information includes make and 
model of the vehicle, time and location of the event, crash delta velocity, direction from which the 
impact occurred, if the airbags deployed, whether the vehicle rolled over, and if there were multiple 
impacts. 


2.2 Opening the Application 

To access the application, a user must open a web browser, such as Internet Explorer, Firefox, Google 
Chrome, or Safari. In the address bar enter the address of the application: https://montana- 
aacn.cubrc.org. If a security certificate error appears, please continue to the webpage. This just means 
the site is using a secure protocol to send and receive the data, but does not have a trusted issuer of the 
certificate yet. Once on the home page, the user can review introductory material and navigate to other 
web pages, which include a description of how the AACN data is acquired, the stakeholders involved, 
links to additional background material, and where to ‘contact us’ to request a username and password. 
In the upper right hand corner of the home page, there is a button labeled ‘Data’. This will take you to a 
login screen. Enter the username and password provided and then click ‘Submit’. 


3. Web Application 


3.1 Data Table 

The data table in the web application provides a summary of the event records present in the database. 
Underneath the data table, there is information pertaining to the number of records in the database and 
the page you are currently viewing. 


3.1.1 Select a Record 
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To select a record from the data table, use your mouse to scroll over the desired row and left-click. Once 
a record is selected, it will be highlighted in the data table. If you hover your mouse over the ‘event 
record’ link directly below the table, a text box will appear which describes the types of calls currently 
included in the table. This text states: 


“An OnStar call to the 9-1-1 PSAP is made for three types of events: 1) an AACN crash which will 
provide crash location, TSP Case ID and AACN data (Delta V, Direction of Impact, Injury Severity 
Prediction, etc.), 2) an ACN crash which will provide crash location only, and 3) an emergency 
call initiated by pushing the SOS button in OnStar vehicle, which will provide OnStar vehicle 
location only. Currently, all three types of calls are listed. “ 


3.1.2 Paging 

If there are more records in the database than what can currently be shown on the page, the data will 
be paged. To change pages, click either ‘First’, ‘Last’, ‘Next’, or ‘Previous’, and the data in the table will 
change. 


3.1.3 Sorting the Data 

The data table provides multiple fields upon which the data can be sorted. To sort on a given field, go to 
the header of the table and left-click on the given field. The data table will update and the direction of 
the sort will be given by the direction of the arrow. An up pointing arrow indicates ascending and down 
pointing indicates descending. To change the direction of the sort, click on the header of the same field. 


3.1.4 Number of Records Displayed 

To change the number of rows displayed in the data table, above the data table there is a drop down 
box, left-click on this and select the desired number of rows to be shown. The data table will update 
displaying the new number of rows and the information associated with the selection. 


3.2 AACN Crash Data 

When an event record is selected from the data table, the AACN Crash Data will automatically expand 
and populate the fields associated crash records data. To expand the collapsed view or to collapse an 
expanded view, go the text ‘AACN Crash Data’ with the arrow and left-click. 


To print the data displayed, underneath the ‘AACN Crash Data’ with the arrow, left-click on the ‘Print 
Summary’ button. This will open a new page with the data in a printer-friendly format and at the top left 
of the screen will be a link ‘Click to Print This Page’ to bring up your print options. 


3.3 Map 

When an event record is selected from the data table, the approximate location of where the event 
happened will be pinned. The view will not automatically expand. To expand the collapsed view or to 
collapse an expanded view, go the text ‘Map’ with the arrow and left-click. If a pin icon showing the 
crash location does not show on the map, click on highlighted record in the table to initiate. This is 
typically only required the first time the map is opened. 


To print the map displayed, underneath the ‘Map’ with the arrow, left-click on the ‘Print Map’ button. 
This will open a new page with the map in a printer-friendly format. 


3.4 Search 
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To the right of the data table, a form provides the ability to search for specific records in the database. 
There are three values that need to be set: Field, Operation, and Value. First select the field, or column, 
upon which you would like to search. Depending on the data type of the field, the operation and value 
may update. For instance, if the data type contains numeric values, the operation drop down box will 
contain: ‘Equals’, ‘Greater than’, ‘Greater than or equal to’, ‘Less than’, and ‘Less than or equal to’. 
Finally, enter the desired value to search for and at the bottom of the search form, left-click the ‘Submit’ 
button. Once a search is conducted, the data table will update and the current search value will be 
displayed below the search form. To remove the current search value, at the bottom of the search form, 
left-click the ‘Clear’ button. (Note: Functionality for some search parameters will not be apparent until 
sufficient AACN event records are contained in the database. For example, Good Samaritan SOS calls are 
not crashes involving the OnStar vehicle and therefore produce no crash data.) 


3.5 Logout 
To logout and end your session, go the upper right hand corner of the page and click on the ‘Logout’ 
button. 


4. Administration 


4.1 Change Password 

To change your password, go the upper right hand corner of the page and click on the ‘Change 
Password’ button. This will redirect to another page containing a form with three fields, current 
password, new password, and retype password, which need to be filled out. Once all three fields are 
completed, at the bottom of the form, left-click the ‘Change’ button. If the process was successful, a pop 
box will appear that says ‘Password change successfull’, if not an error message will appear above the 
form. 


4.2 Admin Users 

An admin user is a user deemed responsible for multiple users with an organization. They have the 
ability to add users, remove users, and change a user’s password in the system. To access the Admin 
page, go the upper right hand corner and left-click the ‘Admin’ button. The ‘Admin’ button will only 
appear if user has Admin privileges. 


4.2.1 Adding Users 

To add a user to the system, expand the ‘Add User’ view by going to the text ‘Add User’ with the arrow 
and left-clicking. This displays a form with four fields: Username, Password, Verify Password, and Email. 
Once all four fields are filled out, go to the bottom of the form and left-click the ‘Submit’ button. If the 

process was successful, a pop box will appear that says ‘User created successfully’ and the form will be 

cleared, if not an error message will appear above the form. 


4.2.2 Deleting Users 

To delete a user from the system, expand the ‘Delete User’ view by going to the text ‘Delete User’ with 
the arrow and left-clicking. Select the desired user to remove from the system by left-clicking on them 
and then left-clicking the ‘Delete’ button beneath the selection box. If the process was successful, a pop 
box will appear that says ‘User deleted successfully’. 


4.2.3 Change a User’s Password 

To change a user’s password, expand the ‘Change User’s Password’ view by going to the text ‘Change 
User’s Password’ with the arrow and left-clicking. Select the desired user’s password to change by left- 
clicking on them and filling out two fields: Password and Verify Password. Once complete, go to the 
bottom of the form and left-click the ‘Change’ button. If the process was successful, a pop box will 
appear that says ‘Password change successfully’, if not an error message will appear above the form. 
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